RACI RevOps: Matriks Kepemilikan untuk Revenue Operations

RevOps rusak ketika semua orang sepakat bahwa pekerjaan itu penting tetapi tidak ada yang sepakat siapa yang memiliki keputusan.

Siapa yang menyetujui tahap siklus hidup baru? Siapa yang memiliki field sumber? Siapa yang memutuskan apakah aturan lead routing berubah? Siapa yang menyelesaikan sengketa antara atribusi marketing dan pelaporan finance?

RACI RevOps menjawab pertanyaan-pertanyaan itu sebelum menjadi urusan politik.

Jika Anda membutuhkan model dasarnya, lihat Matriks RACI dan RACI vs RASCI vs DACI.

PMI menjelaskan RACI sebagai cara untuk memperjelas tanggung jawab dan akuntabilitas sehingga pekerjaan tidak jatuh di antara tim. Dalam RevOps, kejelasan itu penting karena pekerjaannya melintasi marketing, sales, customer success, finance, data, dan sistem.

Model tanggung jawab RevOps dari Forrester menjadi pengingat berguna bahwa RevOps secara alami memiliki cakupan luas. RACI menjaga agar keluasan itu tidak berubah menjadi ambiguitas.

Fakta operasional utama

• RACI RevOps harus memetakan keputusan yang berulang, bukan hanya tugas proyek. Pertanyaan sulit biasanya seputar definisi, kepemilikan data, perubahan sistem, aturan forecast, serah terima, dan pelaporan eksekutif.
• Setiap keputusan membutuhkan satu pemilik yang bertanggung jawab. Input bersama itu sehat. Akuntabilitas bersama sering menciptakan penundaan dan eskalasi politis.
• RevOps tidak boleh dibuat bertanggung jawab atas hasil tanpa otoritas. Jika RevOps memiliki kualitas data, ia harus bisa menyetujui, menolak, atau mengeskalasi perubahan field dan alur kerja.
• RACI bekerja paling baik ketika dipasangkan dengan mandat perekrutan. Perekrutan RevOps pertama membutuhkan hak keputusan yang sesuai dengan matriks kepemilikan.

Apa arti RACI dalam RevOps

RevOps sering harus bertanggung jawab (accountable) atas sistem meskipun tim lain bertanggung jawab (responsible) atas eksekusi lokal.

Perbedaan ini penting. Manajer sales mungkin bertanggung jawab (responsible) membina rep untuk mencatat langkah selanjutnya. RevOps mungkin bertanggung jawab (accountable) atas definisi tahap, field wajib, aturan dashboard, dan irama inspeksi yang membuat langkah selanjutnya itu berguna. Finance mungkin dikonsultasikan karena data opportunity yang sama memberi masukan pada perencanaan.

Itulah sebabnya desain RACI RevOps membutuhkan lebih banyak perhatian daripada RACI proyek biasa. Hasilnya bukan hanya satu pengiriman proyek. Ini adalah model operasi yang berdiri terus-menerus. Di mana hak keputusan berada juga bergantung pada apakah Anda menjalankan RevOps terpusat vs tertanam.

RACI inti RevOps

Tabel ini adalah titik awal. Sesuaikan dengan struktur perusahaan Anda.

Cara membangun RACI RevOps

Mulailah dari keputusan, bukan departemen.

RACI yang lemah dimulai dengan daftar tim dan bertanya, "Apa yang dimiliki setiap tim?" Itu biasanya mencerminkan politik yang sudah ada. RACI yang lebih kuat dimulai dengan keputusan berulang yang menciptakan gesekan:

• Apa yang dihitung sebagai lead terkualifikasi?
• Kapan sebuah deal bisa masuk ke tahap 3?
• Siapa yang bisa membuat field wajib baru?
• Laporan mana yang menjadi sumber kebenaran untuk pipeline?
• Siapa yang menyetujui perubahan routing?
• Siapa yang memutuskan kategori forecast?
• Data apa yang harus mengalir dari sales ke CS?
• Siapa yang memiliki taksonomi alasan churn?

Setelah mendaftar keputusan, tetapkan peran.

Untuk setiap keputusan, pilih satu pemilik yang bertanggung jawab (accountable). Kemudian identifikasi siapa yang mengerjakan pekerjaan, siapa yang harus memberi masukan, dan siapa yang perlu diinformasikan. Jika ada dua pemilik accountable, berhenti dan selesaikan itu. Input bersama itu baik-baik saja. Akuntabilitas bersama biasanya berarti tidak ada yang bisa membuat keputusan akhir.

Bangun inventaris keputusan terlebih dahulu

RACI RevOps yang paling berguna dimulai dengan inventaris keputusan.

Daftarkan keputusan berulang yang menciptakan kebingungan:

Inventaris ini harus didasarkan pada gesekan nyata, bukan kelengkapan teoretis. Ambil contoh dari kuartal terakhir: laporan yang disengketakan, serah terima yang gagal, permintaan field yang berantakan, ketidaksepakatan forecast, pengecualian routing, dan pembangunan ulang dashboard. Itulah keputusan-keputusan yang harus diperjelas RACI terlebih dahulu.

Setelah inventaris ada, kelompokkan keputusan berdasarkan risiko. Keputusan berisiko rendah bisa bergerak cepat dengan RevOps dan pemilik sistem. Keputusan berisiko tinggi membutuhkan persetujuan finance, kepemimpinan fungsional, atau eksekutif.

Tampilan risiko ini menjaga RACI agar tidak memperlambat setiap perubahan kecil. Ini juga mencegah perubahan berdampak tinggi terjadi melalui permintaan santai.

RACI berdasarkan siklus hidup pendapatan

RACI RevOps yang bermanfaat memetakan kepemilikan di seluruh siklus hidup:

Tampilan ini membantu para pemimpin melihat mengapa RevOps tidak bisa hanya menjadi fungsi dukungan sales. Sistem operasional yang sama membentang di seluruh perjalanan.

RACI untuk perubahan CRM dan pelaporan

Perubahan CRM adalah tempat di mana kepemilikan yang samar menjadi mahal.

Gunakan RACI terpisah untuk perubahan sistem:

Ini mencegah kesalahan paling umum: membiarkan fungsi mana pun mengubah struktur data bersama untuk kebutuhan lokal.

Aturan untuk menyelesaikan konflik

Bahkan RACI yang baik tidak akan menghilangkan semua konflik.

Tambahkan aturan eskalasi:

• Jika sengketa hanya memengaruhi satu fungsi, pemimpin fungsional memutuskan.
• Jika sengketa memengaruhi data bersama, RevOps memutuskan atau merekomendasikan.
• Jika sengketa memengaruhi forecast, perencanaan, atau pelaporan dewan, RevOps dan finance harus selaras sebelum diluncurkan.
• Jika sengketa memengaruhi pengalaman pelanggan lintas tim, CRO atau COO memutuskan.
• Jika sengketa memengaruhi trade-off tingkat perusahaan, sponsor eksekutif memutuskan.

Aturan eskalasi penting karena RevOps sering berada di antara pemimpin-pemimpin kuat dengan kebutuhan yang sah. RACI harus membuat jalur keputusan terlihat sebelum konflik menjadi personal.

Aturan untuk menggunakan RACI

Satu pemilik accountable. Beberapa orang yang dikonsultasikan itu baik-baik saja. Beberapa pemilik accountable menciptakan kebuntuan.

Pemimpin fungsional tetap memiliki kinerja. RevOps bisa memiliki sistemnya, tetapi pemimpin sales tetap memiliki kinerja sales dan pemimpin CS tetap memiliki eksekusi retensi.

Hak keputusan harus sesuai dengan tanggung jawab. Jangan membuat RevOps accountable atas kualitas data jika ia tidak bisa menegakkan tata kelola field.

Tinjau ulang setelah perubahan organisasi. RACI menjadi basi ketika tim, sistem, atau motion GTM berubah.

Kesalahan RACI yang umum

Terlalu banyak pemilik accountable. Ini adalah kegagalan yang paling umum. Jika dua pemimpin bertanggung jawab (accountable), tidak ada yang memiliki mandat yang bersih.

RevOps responsible tetapi tidak diberdayakan. Jangan membuat RevOps accountable atas kualitas data jika ia tidak bisa menolak field bernilai rendah, mengubah kriteria tahap, atau menegakkan aturan serah terima.

Finance diinformasikan terlalu terlambat. Jika sebuah metrik muncul dalam pelaporan dewan, finance biasanya harus dikonsultasikan sebelum definisi berubah.

Tim ops tertanam mengikuti aturan yang berbeda. Marketing Ops, Sales Ops, dan CS Ops bisa tetap dekat dengan fungsi mereka, tetapi definisi bersama membutuhkan satu model tata kelola.

RACI tidak digunakan dalam intake. Jika permintaan masih datang sebagai "bisakah kamu membangun ini?", RevOps akan menjadi antrean tiket. Intake harus bertanya keputusan mana yang terpengaruh oleh permintaan itu dan siapa yang accountable.

Irama tinjauan

Tinjau ulang RACI RevOps setiap kuartal, dan lebih cepat setelah perubahan besar.

Pemicunya meliputi:

• CRO, CMO, pemimpin CS, CFO, atau COO baru
• Motion GTM baru
• Perubahan CRM atau sistem besar baru
• Akuisisi atau pemisahan unit bisnis
• Perpindahan dari fokus bisnis baru ke fokus ekspansi
• Sengketa berulang tentang area kepemilikan yang sama

RACI bukan dokumen statis. Ini adalah kesepakatan kerja. Jika para pemimpin berhenti menggunakannya, kepemilikan akan kembali menjadi kekuasaan informal dan perdebatan berulang.

Model rapat

RACI harus digunakan dalam rapat operasional yang berulang, bukan disimpan dalam sebuah folder.

Gunakan dalam:

• Tinjauan roadmap RevOps
• Tinjauan perubahan sistem
• Tinjauan tata kelola forecast
• Tinjauan definisi funnel
• Tinjauan kualitas lead
• Tinjauan serah terima closed-won
• Tinjauan definisi dashboard

Setiap rapat harus menjawab pertanyaan kepemilikan yang sama:

• Keputusan mana yang sedang kita buat?
• Siapa yang accountable?
• Siapa yang harus dikonsultasikan sebelum keputusan?
• Siapa yang perlu diinformasikan setelah keputusan?
• Data atau bukti apa yang dibutuhkan?
• Apa yang berubah dalam sistem setelah keputusan?

Ini membuat RACI praktis. Para pemimpin tidak perlu menghafal dokumen. Mereka perlu kebiasaan menggunakan bahasa kepemilikan ketika sistem pendapatan berubah.

Contoh: perubahan lead routing

Misalkan sales ingin lead enterprise dirutekan langsung ke AE senior, sementara marketing ingin lead itu dirutekan terlebih dahulu ke SDR untuk kualifikasi.

Tanpa RACI, ini menjadi perdebatan soal preferensi.

Dengan RACI:

• RevOps bertanggung jawab (responsible) memetakan logika routing dan dampak SLA.
• CRO bertanggung jawab (accountable) atas keputusan alur kerja pendapatan.
• Marketing, kepemimpinan SDR, manajer sales, dan finance dikonsultasikan.
• SDR, AE, dan pemilik kampanye marketing diinformasikan setelah perubahan.

RevOps kemudian bisa menguji dampak operasionalnya: waktu respons, tingkat penerimaan, tingkat konversi, kapasitas pemilik, dan perubahan pelaporan. RACI tidak memutuskan strateginya, tetapi membuat jalur keputusan menjadi bersih.

Contoh: field wajib baru

Field wajib adalah sumber gesekan yang umum.

Sales mungkin menolak karena field memperlambat alur kerja rep. Marketing mungkin menginginkan lebih banyak data segmentasi. CS mungkin membutuhkan konteks serah terima. Finance mungkin membutuhkan pelaporan yang lebih bersih.

RACI membantu memisahkan nilai field dari kepemilikan field:

• Tim yang meminta bertanggung jawab (responsible) menjelaskan keputusan yang didukung field itu.
• RevOps bertanggung jawab (accountable) atas tata kelola field.
• Sistem bertanggung jawab (responsible) atas konfigurasi.
• Manajer terdampak dikonsultasikan.
• Pengguna diinformasikan dengan catatan peluncuran yang jelas.

RevOps hanya boleh menyetujui field itu jika mendukung keputusan atau alur kerja nyata. Jika field itu hanya mendukung keingintahuan sesekali, field itu harus tetap opsional atau dipindahkan ke titik penangkapan yang berbeda.

Otoritas harus sesuai dengan akuntabilitas

RACI bisa terlihat bersih di atas kertas dan tetap gagal jika otoritas tidak ada.

Ketidaksesuaian umum:

Perbaiki kesenjangan otoritas sebelum menerbitkan matriks. Jika RevOps accountable atas tata kelola, para pemimpin harus menerima bahwa RevOps bisa menghentikan permintaan bernilai rendah, mewajibkan definisi, dan mengeskalasi konflik. Jika pemimpin fungsional memiliki perilaku, mereka harus memeriksanya di tim mereka. Jika finance dikonsultasikan tentang metrik perencanaan, finance membutuhkan tempat sebelum metrik itu diluncurkan, bukan setelahnya.

RACI juga harus menyatakan apa yang terjadi ketika pemilik accountable tidak memutuskan. Misalnya, jika sengketa siklus hidup menghambat pelaporan lebih dari dua minggu, CRO atau COO mungkin perlu membuat keputusan akhir. Tanpa eskalasi, RACI menamai kepemilikan tetapi tidak menyelesaikan keputusan yang terhenti.

Bagaimana RACI terhubung dengan charter

Charter RevOps mendefinisikan mandat. RACI mendefinisikan siapa yang bertindak di dalam mandat itu.

Gunakan charter untuk menjawab, "Apakah ini termasuk cakupan RevOps?"

Gunakan RACI untuk menjawab, "Siapa yang memutuskan, siapa yang mengerjakan, siapa yang memberi masukan, dan siapa yang diberi tahu?"

Bersama-sama, keduanya menciptakan disiplin operasional. Secara terpisah, keduanya lebih lemah. Charter tanpa RACI terlalu luas. RACI tanpa charter mungkin memperjelas tugas tetapi kehilangan tujuan fungsi tersebut.

Versi ringan untuk tim kecil

Perusahaan kecil tidak membutuhkan matriks kepemilikan raksasa.

Mulailah dengan lima keputusan:

• Definisi siklus hidup
• Lead routing
• Aturan tahap opportunity
• Kategori forecast
• Kebutuhan serah terima closed-won

Untuk masing-masing, sebutkan satu pemilik accountable dan satu peran RevOps. Itu sudah cukup untuk mengurangi kebingungan tanpa memperlambat perusahaan.

Seiring perusahaan menambah segmen, motion, sistem, dan spesialis ops, perluas RACI. Model ini harus tumbuh seiring kompleksitas.

Daftar periksa kesiapan RACI

Sebelum menerbitkan matriks, ujilah terhadap konflik-konflik terbaru.

Pilih tiga contoh nyata dari kuartal terakhir:

• Definisi lead yang disengketakan
• Perubahan aturan forecast
• Ketidaksepakatan metrik dashboard
• Permintaan field wajib
• Kegagalan serah terima closed-won
• Eskalasi routing

Untuk setiap contoh, tanyakan apakah RACI membuat jalur keputusan menjadi jelas. Jika para pemimpin masih tidak bisa mengatakan siapa yang accountable, matriks itu belum siap.

Uji juga apakah pemilik accountable memiliki otoritas untuk bertindak. RACI yang menetapkan akuntabilitas tanpa otoritas akan menciptakan frustrasi. Jika RevOps accountable atas tata kelola field, ia harus bisa menyetujui, menolak, atau mengeskalasi perubahan field. Jika sales accountable atas akurasi tahap, manajer membutuhkan irama inspeksi dan konsekuensi untuk kebersihan yang buruk.

Uji terakhir adalah kemudahan penggunaan. RACI harus muat dalam beberapa halaman dan mudah dipindai. Jika matriks itu begitu rinci sehingga tidak ada yang menggunakannya, mulailah lebih kecil dan fokus pada keputusan yang menciptakan gesekan pendapatan terbesar.

Setelah matriks aktif, rujuklah dalam setiap perubahan sistem atau proses yang berarti. Penggunaan berulang itulah yang mengubah kepemilikan dari dokumen menjadi perilaku operasional dan mengurangi perdebatan berulang.

Cara menjaga RACI tetap ringan

RACI harus cukup rinci untuk menyelesaikan konflik, tetapi tidak terlalu rinci sehingga tidak ada yang membukanya.

Gunakan tiga tingkat:

Model berlapis ini membantu perusahaan kecil menghindari proses yang berlebihan sambil memberi tim yang lebih besar kontrol yang cukup. Pembersihan laporan kecil tidak seharusnya membutuhkan komite pengarah. Perubahan definisi kategori forecast tidak seharusnya terjadi di dalam sebuah tiket.

Tanda terbaik bahwa RACI berfungsi bukanlah orang-orang mengutipnya terus-menerus. Tandanya adalah lebih sedikit keputusan yang terhenti karena semua orang sudah tahu jalurnya.

Pertanyaan intake RACI

Gunakan RACI pada saat permintaan masuk ke RevOps.

Alih-alih hanya bertanya "apa yang perlu kamu bangun?", intake harus bertanya:

• Keputusan bisnis mana yang terpengaruh oleh permintaan ini?
• Field, alur kerja, dashboard, atau serah terima mana yang berubah?
• Siapa yang accountable atas hasil bisnisnya?
• Siapa yang perlu dikonsultasikan sebelum implementasi?
• Tim mana yang perlu diinformasikan setelah peluncuran?
• Apakah finance perlu meninjau definisinya?
• Apakah perubahan ini memengaruhi pelaporan eksekutif atau forecast?
• Apa yang terjadi jika permintaan ini ditolak atau ditunda?

Pertanyaan-pertanyaan ini memperlambat permintaan yang lemah sebelum menjadi pekerjaan sistem. Sebuah tim yang meminta dashboard baru mungkin belum memiliki definisi metrik. Seorang pemimpin yang meminta field wajib mungkin tidak tahu siapa yang memiliki nilainya. Seorang manajer yang meminta pengecualian routing mungkin belum mempertimbangkan dampak kapasitas atau pelaporan.

Proses intake tidak perlu berat. Ini bisa berupa formulir singkat atau daftar periksa di dalam backlog RevOps. Bagian pentingnya adalah setiap permintaan yang berarti terikat pada pemilik accountable dan jalur keputusan.

Ini juga melindungi kapasitas RevOps. Tanpa disiplin intake, tim menghabiskan waktu membangun perbaikan lokal yang menciptakan kompleksitas bersama. Dengan intake berbasis RACI, RevOps bisa menjelaskan mengapa beberapa permintaan bergerak cepat, beberapa membutuhkan konsultasi, dan beberapa tidak seharusnya dibangun.

Tanda-tanda RACI berfungsi

Perhatikan perubahan perilaku:

• Permintaan field datang dengan pemilik, definisi, dan alasan bisnis.
• Sengketa dashboard diselesaikan melalui aturan sumber kebenaran yang disepakati.
• Perubahan aturan forecast melibatkan sales, finance, dan RevOps sebelum diluncurkan.
• Kegagalan serah terima mengarah pada perubahan kepemilikan, bukan hanya pengingat.
• Tim tahu siapa yang memutuskan sebelum rapat dimulai.
• RevOps menghabiskan lebih sedikit waktu menengahi perdebatan berulang.

RACI berhasil ketika keputusan menjadi lebih cepat dan lebih jelas. Ini harus mengurangi waktu rapat, menurunkan pengerjaan ulang, dan membuat eskalasi kurang bersifat personal.

Paket keputusan RACI

Gunakan paket keputusan ketika kepemilikan disengketakan.

Ini mencegah RACI menjadi dokumen statis. Ini menjadi berguna ketika para pemimpin menggunakannya untuk menyelesaikan keputusan operasional yang nyata.

FAQ

Apakah RevOps membutuhkan RACI?

Ya, begitu beberapa tim bergantung pada sistem pendapatan yang sama. Tanpa RACI, serah terima dan kepemilikan data menjadi informal.

Siapa yang harus bertanggung jawab (accountable) atas akurasi forecast?

Kepemimpinan sales biasanya memiliki hasil forecast. RevOps memiliki proses forecast, definisi, kualitas data, dan irama inspeksi. Finance adalah mitra kunci yang dikonsultasikan.

Apakah RACI cukup untuk pengambilan keputusan?

Terkadang. Untuk keputusan bertaruhan tinggi, DACI mungkin lebih baik karena secara eksplisit mendefinisikan penggerak dan penyetuju keputusan.

Pelajari lebih lanjut

• Charter RevOps
• RevOps dan Finance
• Tata Kelola Forecast
• Glosarium Keselarasan Marketing-Sales