Piagam RevOps: Cara Menetapkan Mandat, Ruang Lingkup, dan Hak Keputusan

Piagam RevOps adalah dokumen yang mencegah Revenue Operations bertanggung jawab atas segalanya namun tidak berwenang mengubah apa pun.

Tanpa piagam, RevOps akan menjadi apa pun yang dibutuhkan pemangku kepentingan paling vokal minggu itu: tim dashboard, antrean admin CRM, fungsi pembersihan forecast, atau jalur eskalasi untuk frustrasi lintas fungsi.

Piagam memberi fungsi ini sebuah mandat.

Riset model operasi RevOps dari Forrester menjelaskan inti masalahnya dengan gamblang: keberhasilan RevOps bergantung pada desain operasi, bukan sekadar nama tim. Panduan Gartner tentang mengurangi kompleksitas revenue enablement menunjukkan masalah yang sama dari sisi penjualan: inisiatif yang terputus-putus menciptakan kebisingan kecuali ada yang mengelola model bersama tersebut.

Piagam mengubah model itu menjadi bahasa yang sederhana. Piagam memberi tahu para pemimpin apa yang dimiliki RevOps, apa yang dipengaruhinya, apa yang bukan miliknya, dan bagaimana keputusan dibuat.

Fakta operasi utama

• Piagam RevOps menetapkan mandat, ruang lingkup, hak keputusan, irama tata kelola, otoritas sistem, metrik, dan jalur eskalasi.
• Piagam harus melindungi RevOps agar tidak bertanggung jawab atas segalanya sekaligus tidak berwenang mengubah apa pun.
• Piagam yang kuat memisahkan kepemilikan kinerja fungsional dari kepemilikan sistem operasi bersama.
• Piagam harus ditinjau ulang saat perusahaan mengubah motion GTM, sistem, kepemimpinan, kebutuhan pelaporan, atau struktur RevOps.

Apa yang harus dicakup dalam piagam RevOps

Piagam harus cukup singkat agar para pemimpin mau membacanya, dan cukup spesifik agar dapat menyelesaikan perdebatan.

Mengapa RevOps membutuhkan piagam

RevOps sering kali dimulai karena satu orang pandai menemukan keteraturan dalam sistem yang berantakan. Mereka membersihkan laporan, memperbaiki field, menerjemahkan antara marketing dan sales, dan membantu finance memahami apa yang terjadi di funnel.

Kegunaan itu menciptakan permintaan. Tak lama kemudian, semua orang menginginkan sesuatu dari RevOps.

Marketing menginginkan pembersihan atribusi. Sales menginginkan perubahan wilayah. CS menginginkan field handoff yang lebih baik. Finance menginginkan kepercayaan forecast. Leadership menginginkan dashboard. Tim sistem menginginkan lebih sedikit permintaan workflow yang terburu-buru. Setiap permintaan mungkin masuk akal, tetapi beban gabungannya bisa mengubah RevOps menjadi sekadar antrean tugas.

Piagam mencegah pergeseran itu.

Piagam menjawab lima pertanyaan praktis:

• Apa yang ingin ditingkatkan oleh RevOps di sini?
• Bagian mana dari sistem pendapatan yang dimilikinya?
• Keputusan mana yang bisa diambilnya?
• Keputusan mana yang memerlukan persetujuan eksekutif?
• Bagaimana para pemimpin tahu apakah RevOps berjalan efektif?

Tanpa jawaban tersebut, RevOps mendapat tanggung jawab tanpa otoritas. Itulah salah satu alasan fungsi ini gagal bahkan ketika timnya berbakat.

Tabel keputusan piagam

Piagam harus mempermudah keputusan yang umum terjadi.

Di sinilah piagam menjadi praktis. Piagam tidak boleh hanya mendeskripsikan RevOps dengan bahasa yang umum. Piagam harus membantu para pemimpin menyelesaikan keputusan yang biasanya menciptakan gesekan.

Pernyataan misi

Pernyataan misi RevOps yang berguna terdengar seperti ini:

RevOps memiliki sistem operasi yang membuat pendapatan dapat diprediksi di seluruh marketing, sales, customer success, finance, data, dan sistem.

Misi itu terhubung langsung dengan Apa Itu Revenue Operations?. Misi ini memposisikan RevOps sebagai pemilik sistem, bukan antrean tugas.

Ruang lingkup

RevOps harus memiliki:

• Definisi siklus hidup pendapatan
• Serah terima lintas fungsi
• Dashboard pendapatan bersama
• Tata kelola data CRM dan pendapatan
• Tata kelola proses forecast
• Irama operasi pendapatan
• Kontrol perubahan sistem untuk workflow pendapatan

RevOps tidak boleh memiliki:

• Strategi marketing
• Coaching sales dan eksekusi deal
• Manajemen hubungan customer success
• Kepemilikan rencana finance
• Keputusan roadmap produk

Piagam harus membuat hal ini eksplisit. RevOps mengoperasionalkan strategi. RevOps tidak menggantikan kepemimpinan fungsional.

Batasan ruang lingkup

Bagian tersulit dalam menulis piagam adalah memutuskan apa yang tidak akan dilakukan RevOps.

Piagam yang menyatakan RevOps memiliki "pertumbuhan pendapatan" terlalu luas. Pertumbuhan pendapatan adalah hasil dari strategi, permintaan pasar, produk, harga, eksekusi sales, customer success, dan perencanaan keuangan. RevOps dapat meningkatkan sistem di balik hasil tersebut, tetapi tidak boleh dimintai pertanggungjawaban atas setiap hasil komersial.

Batasan yang lebih jelas terlihat seperti ini:

Batasan ini melindungi kedua belah pihak. Pemimpin fungsional tetap memiliki kepemilikan atas kinerja. RevOps mendapat otoritas atas lapisan operasi bersama.

Hak keputusan

Hak keputusan adalah bagian terpenting dari piagam.

Tentukan siapa yang dapat menyetujui:

• Tahap siklus hidup baru
• Perubahan field CRM
• Definisi metrik dashboard
• Perubahan aturan perutean
• Aturan kategori forecast
• Persyaratan serah terima
• Alat atau integrasi pendapatan baru

Untuk desain kepemilikan yang lebih rinci, lihat RevOps RACI.

Template hak keputusan

Hak keputusan harus ditulis sebagai tabel, bukan terkubur dalam paragraf.

Nama-nama persisnya bisa berubah, tetapi prinsipnya tidak. RevOps hanya dapat memiliki kualitas sistem jika memiliki hak persetujuan atas perubahan yang memengaruhi kualitas sistem tersebut.

Irama operasi

Piagam juga harus menetapkan rapat-rapat yang dijalankan atau didukung RevOps.

Irama umum meliputi:

• Inspeksi pipeline mingguan
• Peninjauan forecast mingguan atau dua mingguan
• Peninjauan funnel bulanan
• Peninjauan kualitas data bulanan
• Peninjauan perubahan sistem bulanan
• Peninjauan definisi siklus hidup dan dashboard triwulanan
• Peninjauan roadmap RevOps triwulanan

Tujuannya bukan lebih banyak rapat. Tujuannya adalah lebih sedikit eskalasi ad hoc.

Ketika irama tidak ada, setiap ketidaksepakatan menjadi rapat khusus. Ketika irama ada, para pemimpin tahu ke mana harus mengangkat isu, bagaimana keputusan akan dibuat, dan kapan perubahan akan ditinjau.

Untuk ritme operasi yang lebih luas, lihat Irama Pendapatan.

Tata kelola sistem

Sebagian besar piagam RevOps gagal karena kurang merinci tata kelola sistem.

Jika CRM adalah inti operasi, maka perubahan field, workflow, integrasi, data wajib, perutean lead, aturan tahap, dan definisi dashboard tidak bisa diubah sembarangan. Perubahan kecil menciptakan efek hilir.

Piagam harus menetapkan:

• Siapa yang dapat mengajukan perubahan
• Informasi apa yang harus disertakan dalam permintaan
• Bagaimana RevOps mengevaluasi dampak
• Siapa yang menyetujui perubahan berisiko tinggi
• Bagaimana perubahan didokumentasikan
• Bagaimana pengguna diberi tahu
• Bagaimana adopsi diperiksa setelah peluncuran

Ini sangat penting ketika beberapa tim berbagi objek yang sama. Sebuah field yang membantu segmentasi marketing mungkin memperlambat entri sales. Sebuah workflow yang membantu perutean sales mungkin memengaruhi serah terima CS. Definisi dashboard yang membantu CRO mungkin bertentangan dengan pelaporan finance.

RevOps tidak perlu memblokir perubahan. RevOps perlu membuat perubahan terlihat sebelum merusak sesuatu.

Peluncuran piagam

Jangan menerbitkan piagam sebagai dokumen final dan berharap langsung diadopsi.

Peluncuran harus menjadi proses penyelarasan kepemimpinan:

1. RevOps menyusun draf piagam dari titik-titik masalah saat ini.
2. Pemimpin fungsional meninjau ruang lingkup dan hak keputusan.
3. Finance meninjau definisi metrik dan titik sentuh perencanaan.
4. Sistem atau IT meninjau tata kelola platform.
5. Sponsor eksekutif menyelesaikan konflik.
6. Piagam final dibagikan kepada manajer pendapatan.
7. RevOps menggunakan piagam dalam intake, prioritisasi, dan peninjauan roadmap.

Piagam harus cukup singkat untuk digunakan dalam keputusan nyata. Jika tidak ada yang membukanya setelah diluncurkan, piagam itu terlalu teoretis.

Contoh bahasa piagam

Gunakan bahasa yang sederhana:

RevOps memiliki sistem operasi pendapatan bersama di seluruh marketing, sales, customer success, finance, dan sistem. RevOps mengatur definisi siklus hidup, serah terima, kualitas data CRM, pelaporan sumber kebenaran, proses forecast, irama pendapatan, dan dampak perubahan sistem. Pemimpin fungsional memiliki kinerja tim, strategi, coaching, dan eksekusi pelanggan. RevOps memiliki otoritas untuk menyetujui atau menolak perubahan yang memengaruhi data pendapatan bersama, workflow, dashboard, dan serah terima, dengan eskalasi eksekutif ketika trade-off memengaruhi prioritas tingkat perusahaan.

Paragraf itu tidak menyelesaikan setiap perselisihan, tetapi memberi perusahaan titik awal. Paragraf itu juga membuat fungsi ini konkret. RevOps bukan "keselarasan". RevOps adalah pemilik lapisan operasi yang ditetapkan.

Metrik

RevOps harus diukur berdasarkan kesehatan sistem, bukan volume tiket.

Metrik yang baik meliputi:

• Akurasi forecast
• Kepatuhan SLA
• Kelengkapan serah terima
• Kelengkapan field wajib
• Visibilitas sumber-ke-pendapatan
• Kepercayaan dashboard
• Pengurangan pelaporan manual
• Pengurangan penuaan tahap

Gunakan Metrik RevOps sebagai basis metrik.

Alur kerja persetujuan piagam

Piagam RevOps harus disetujui melalui lensa lintas fungsi yang sama dengan yang akan diaturnya.

Proses persetujuan ini penting karena piagam adalah dokumen kekuasaan. Piagam menetapkan siapa yang dapat menyetujui atau menolak perubahan yang memengaruhi kebenaran pendapatan bersama. Jika hanya RevOps yang menyetujuinya, tim lain mungkin menganggapnya sebagai preferensi internal, bukan kebijakan operasi perusahaan.

Cara menggunakan piagam dalam permintaan nyata

Piagam harus mengubah perilaku sehari-hari.

Jika piagam tidak dapat menjawab permintaan umum ini, piagam itu terlalu samar. Perketat hak keputusan sebelum menambah proses.

Cara menjaga piagam tetap relevan

Piagam RevOps harus berubah ketika perusahaan berubah.

Tinjau ulang saat:

• Perusahaan menambahkan motion GTM baru
• Marketing, sales, atau CS melakukan reorganisasi
• Jalur pelaporan RevOps berubah
• CRM baru atau sistem pendapatan besar diperkenalkan
• Finance mengubah model perencanaan
• Perusahaan beralih dari fokus bisnis baru ke fokus perpanjangan dan ekspansi
• Leadership berulang kali mengeskalasi konflik kepemilikan yang sama

Jangan menulis ulang piagam setiap bulan. Tetapi jangan biarkan piagam menjadi artefak dari model operasi lama. Piagam yang basi lebih buruk daripada tidak ada piagam sama sekali karena memberi orang kejelasan palsu.

Piagam terbaik adalah alat yang hidup: dirujuk dalam peninjauan roadmap, tata kelola sistem, keputusan intake, dan perselisihan lintas fungsi.

Aturan intake

Piagam harus mengubah cara RevOps menerima pekerjaan.

Tanpa aturan intake, setiap permintaan terlihat sama mendesaknya:

• "Bisa tambahkan field ini?"
• "Bisa buatkan dashboard ini?"
• "Bisa perbaiki perutean ini?"
• "Bisa ambilkan laporan ini untuk rapat dewan?"
• "Bisa otomatiskan follow-up ini?"

RevOps membutuhkan cara untuk memisahkan tugas dukungan dari keputusan operasi.

Formulir intake sederhana harus menanyakan:

Piagam harus memungkinkan RevOps menolak atau menunda pekerjaan ketika permintaan tidak memiliki pemilik, keputusan, atau jalur adopsi yang jelas. Ini bukan berarti RevOps menjadi tidak membantu. Ini berarti fungsi tersebut melindungi sistem dari perubahan bermutu rendah.

Pola anti (anti-pattern)

Waspadai kesalahan piagam berikut:

Piagam hanya berupa pernyataan misi. Pernyataan misi memang berguna, tetapi tidak mendefinisikan otoritas. Piagam membutuhkan ruang lingkup, keputusan, metrik, dan eskalasi.

RevOps memiliki setiap masalah pendapatan. Ini menciptakan kebencian dan kegagalan. Pemimpin fungsional tetap memiliki strategi dan eksekusi.

Hak keputusan tidak jelas. Jika piagam menyatakan RevOps "bermitra dalam" segalanya, tidak ada yang tahu kapan RevOps boleh menolak.

Tata kelola sistem tidak ada. Perubahan field, workflow, dan dashboard adalah titik di mana kualitas operasi sering rusak.

Piagam hanya disetujui oleh RevOps sendiri. Piagam membutuhkan dukungan eksekutif. Jika tidak, piagam hanyalah daftar keinginan.

Piagam tidak pernah digunakan dalam trade-off roadmap. Jika para pemimpin menyetujui piagam tetapi tetap mengeskalasi setiap permintaan di sekitarnya, piagam tidak memiliki kekuatan.

Piagam pertama yang praktis

Piagam RevOps pertama tidak perlu mencakup setiap kasus khusus.

Untuk perusahaan tahap pertumbuhan, versi pertama bisa berupa perjanjian operasi dua halaman:

• Misi
• Sistem dan proses yang dimiliki
• Tanggung jawab yang tidak dimiliki
• Tabel hak keputusan
• Aturan intake
• Jalur eskalasi
• Lima metrik kesehatan teratas
• Tanggal peninjauan triwulanan

Itu sudah cukup untuk memulai. Dokumen ini harus terus membaik seiring RevOps mempelajari di mana konflik sesungguhnya berada.

Intinya bukan tata kelola yang sempurna sejak hari pertama. Intinya adalah berhenti berpura-pura bahwa pekerjaan pendapatan lintas fungsi bisa berjalan selamanya hanya dengan itikad baik informal.

Daftar periksa kesiapan piagam

Sebelum menyatakan piagam selesai, periksa apakah piagam dapat menjawab perselisihan operasi nyata:

• Bisakah RevOps menolak permintaan field yang merugikan kualitas data?
• Bisakah para pemimpin membedakan dashboard mana yang menjadi sumber kebenaran?
• Bisakah finance melihat dari mana metrik perencanaan berasal?
• Bisakah sales dan marketing menyelesaikan perselisihan definisi siklus hidup tanpa eskalasi khusus?
• Bisakah CS mensyaratkan data serah terima tanpa negosiasi per kesepakatan?
• Bisakah tim sistem melihat perubahan workflow pendapatan mana yang perlu ditinjau?

Jika jawabannya tidak, piagam kemungkinan masih terlalu lunak. Perketat tabel hak keputusan sebelum peluncuran.

FAQ

Siapa yang menulis piagam RevOps?

RevOps harus menyusun drafnya, tetapi CRO, CEO, finance, marketing, sales, dan pemimpin CS harus meninjau dan menyetujuinya.

Seberapa panjang seharusnya piagam RevOps?

Biasanya dua hingga empat halaman. Piagam harus spesifik, bukan legalistis.

Seberapa sering piagam harus diperbarui?

Tinjau ulang setiap triwulan atau kapan pun perusahaan mengubah motion GTM, jalur pelaporan, sistem, atau proses pendapatan besar.

Pelajari lebih lanjut

• Struktur Tim RevOps
• Mengapa RevOps Gagal
• Irama Pendapatan
• Manajemen Perubahan CRM