Rangka Kerja Revenue Operations: Cara Mereka Bentuk Sistem Operasi Full-Funnel

RevOps gagal apabila syarikat menganggapnya sebagai pasukan pelaporan.

Corak ini biasa. Sesebuah syarikat mengambil operator yang kukuh, memberikan akses CRM, dan meminta dashboard yang lebih baik. Dashboard bertambah baik untuk satu suku tahun. Kemudian masalah yang sama kembali: definisi lead menyimpang, peringkat jualan digunakan secara tidak konsisten, panggilan ramalan bertukar menjadi sesi pembersihan, dan customer success masih menerima serah tugas yang tidak lengkap.

Isunya bukan kemahiran pelaporan. Isunya ialah reka bentuk rangka kerja.

Rangka kerja Revenue Operations yang berguna mentakrifkan cara syarikat menjalankan hasil merentasi strategi, senibina funnel, proses, data, sistem, metrik, irama, dan akauntabiliti. Ia memberi pemimpin cara untuk mengaudit keseluruhan sistem hasil berbanding mengejar simptom yang terputus.

Artikel ini dibina berdasarkan Apakah Revenue Operations?. Versi ringkas: RevOps adalah lapisan operasi merentasi pemasaran, jualan, customer success, kewangan, data, dan sistem. Jika syarikat anda mengangkat kerja ini sebagai reka bentuk pergerakan go-to-market, Operasi GTM berbanding Revenue Operations menerangkan di mana kedua-duanya bertindih. Rangka kerja di bawah menukar definisi itu menjadi model kerja.

Penyelidikan model operasi Forrester membuat perkara yang sama daripada sudut lain: revenue operations memerlukan model operasi, bukan sekadar nama pasukan baharu atau struktur pelaporan.

Fakta operasi utama

• Rangka kerja RevOps perlu mentakrifkan cara syarikat menjalankan hasil merentasi strategi, kitaran hayat, proses, data, sistem, metrik, irama, dan akauntabiliti.
• Bina lapisan mengikut susunan. Dashboard dan automasi perlu mengikut definisi peringkat, peraturan proses, dan tadbir urus data.
• Rangka kerja perlu merangkumi pemerolehan, jualan, customer success, pembaharuan, dan pengembangan.
• Gunakan rangka kerja sebagai alat audit: cari lapisan mana yang lemah sebelum memilih alat, laporan, atau reorganisasi sebagai pembaikan.

Rangka kerja RevOps enam lapisan

Kebanyakan masalah RevOps datang daripada membina lapisan ini tidak mengikut susunan. Dashboard yang dibina sebelum definisi peringkat akan mendedahkan kekeliruan, bukan menyelesaikannya. Automasi yang ditambah sebelum peraturan SLA akan mempercepatkan serah tugas yang rosak. Medan CRM yang ditambah tanpa tadbir urus akan menjadi satu lagi titik data yang tidak konsisten.

Rangka kerja memaksa susunan. Strategi memaklumkan reka bentuk funnel. Reka bentuk funnel memaklumkan proses. Proses mentakrifkan model data. Data menjadikan metrik boleh dipercayai. Metrik menyumbang kepada irama. Irama mencipta akauntabiliti.

Cara menggunakan rangka kerja sebagai audit

Rangka kerja ini paling berguna apabila digunakan terhadap sistem operasi semasa, bukan sebagai latihan reka bentuk kosong.

Pilih laluan hasil terkini dan lalui keenam-enam lapisan. Sebagai contoh, pilih lima permintaan demo inbound, lima peluang outbound, lima deal closed-won, dan lima pelanggan berisiko pembaharuan. Bagi setiap rekod, tanya soalan yang sama.

Audit ini menjadikan rangka kerja konkrit. Jika lead memenuhi ICP tetapi tidak pernah sampai kepada wakil jualan yang betul, lapisan lemah ialah proses dan SLA. Jika pelanggan closed-won sampai ke onboarding tanpa kriteria kejayaan, lapisan lemah ialah data dan reka bentuk serah tugas. Jika pemimpin melihat isu itu tetapi tiada siapa membuat keputusan, lapisan lemah ialah irama.

Kad skor diagnostik

Gunakan kad skor ringkas sebelum memilih projek RevOps seterusnya.

Skorkan setiap lapisan dari 1 hingga 5. Lapisan paling rendah biasanya menerangkan kesakitan berulang.

Sebagai contoh, jika metrik mendapat skor 4 tetapi senibina funnel mendapat skor 2, jangan mulakan dengan membina semula dashboard. Dashboard itu mungkin melaporkan tingkah laku peringkat yang tidak jelas. Jika proses mendapat skor 2 dan data mendapat skor 2, jangan automasi lagi. Automasi hanya akan menggerakkan rekod lemah dengan lebih pantas.

Cara mengutamakan pembaikan

Pasukan RevOps sering mewarisi backlog panjang: permintaan dashboard, pembersihan medan, pembaikan penghalaan, pertikaian atribusi, aduan ramalan, dan perubahan alat. Rangka kerja membantu menyusun keutamaan backlog itu mengikut impak sistem.

Utamakan kerja yang memenuhi sekurang-kurangnya dua daripada syarat ini:

• Ia mempengaruhi lebih daripada satu fungsi hasil.
• Ia mengubah keputusan yang dibuat pemimpin setiap minggu atau bulan.
• Ia menambah baik kepercayaan ramalan, pipeline, serah tugas, atau pembaharuan.
• Ia menghapuskan pembersihan manual berulang.
• Ia menghalang data buruk daripada memasuki sistem.
• Ia mengurangkan geseran yang dihadapi pelanggan.

Kurangkan keutamaan kerja yang hanya kosmetik, hanya tempatan kepada satu pengurus, atau berguna sekali sahaja. Penarikan lembaga pengarah sekali sahaja mungkin mendesak, tetapi ia bukan penambahbaikan rangka kerja melainkan ia menjadi sebahagian daripada model pelaporan yang ditadbir.

Lapisan 1: Strategi hasil

Strategi hasil menjawab soalan operasi pertama: dari mana pertumbuhan patut datang?

RevOps tidak memiliki strategi seorang diri. CEO, CRO, CMO, VP Jualan, ketua CS, dan pemimpin kewangan membuat keputusan strategi. RevOps menukar keputusan itu menjadi keperluan operasi.

Lapisan strategi perlu mentakrifkan:

• Sempadan ICP dan bukan-ICP
• Segmen sasaran dan akaun keutamaan
• Campuran pergerakan jualan, seperti inbound, outbound, partner, pengembangan, atau dipacu produk
• Jalur nilai kontrak purata
• Sasaran pertumbuhan mengikut segmen atau pergerakan
• Andaian kapasiti mengikut pasukan
• Jangkaan pengekalan dan pengembangan

Tanpa lapisan ini, RevOps menjadi reaktif. Ia boleh menghalakan lead, membina dashboard, dan mengekalkan medan, tetapi ia tidak dapat menentukan sama ada sistem tersebut menyokong model pertumbuhan semasa.

Contoh: jika syarikat berpindah daripada inbound SMB kepada outbound mid-market, RevOps mesti menukar medan akaun, pemarkahan lead, penghalaan, peringkat pipeline, pemeriksaan ramalan, dan data serah tugas onboarding. Jika strategi tidak diterjemahkan kepada keperluan sistem, funnel lama terus berjalan di bawah strategi baharu.

Penyelidikan pertumbuhan B2B McKinsey menunjukkan data bersepadu, analitik lanjutan, dan penyelarasan operasi merentasi pasukan komersial sebagai sebahagian daripada apa yang membezakan prestasi B2B yang lebih kukuh. RevOps adalah tempat penyelarasan itu menjadi kerja operasi.

Lapisan 2: Senibina funnel

Senibina funnel mentakrifkan kitaran hayat hasil daripada sentuhan pertama hingga pembaharuan.

Lapisan ini adalah tempat RevOps mendokumenkan peringkat dan menghapuskan kekaburan. Senibina funnel yang baik merangkumi:

• Nama peringkat
• Definisi peringkat
• Kriteria kemasukan
• Kriteria keluar
• Pemilik utama
• Medan wajib
• Peraturan SLA atau masa
• Tindakan sistem seterusnya

Funnel pemerolehan yang ringkas mungkin bergerak daripada pelawat kepada lead, MQL, SQL, peluang, closed-won, onboarded, pelanggan aktif, pembaharuan, dan pengembangan. Syarikat yang lebih kompleks mungkin memisahkan mengikut pergerakan atau segmen. Walau apa pun, disiplinnya sama: tiada peringkat sepatutnya wujud hanya kerana ia kedengaran berguna.

Untuk pengambilan lead, ini berhubung terus dengan Pengurusan Lead berbanding CRM. CRM menyimpan rekod. Pengurusan lead mentakrifkan cara rekod itu perlu bergerak. RevOps memastikan kedua-duanya sepadan.

Ujian terbaik senibina funnel ialah sama ada pengurus baharu dapat memeriksa sepuluh rekod dan tahu dengan tepat mengapa setiap rekod berada dalam peringkat semasanya. Jika tidak, senibina itu terlalu kabur.

Lapisan 3: Reka bentuk proses dan SLA

Proses menukar peringkat funnel menjadi kerja.

RevOps perlu mendokumenkan aliran kerja utama yang menggerakkan hasil antara pasukan:

• Penangkapan dan pengayaan lead
• Tugasan dan penerimaan lead
• Serah tugas MQL kepada SQL
• Penciptaan peluang
• Pemeriksaan pipeline
• Kelulusan sebut harga atau cadangan
• Serah tugas closed-won
• Permulaan onboarding
• Eskalasi risiko pembaharuan
• Penghalaan pencetus pengembangan

Setiap aliran kerja memerlukan SLA. SLA tidak perlu rumit. Ia hanya perlu menjawab: siapa bertindak, bila, dengan data apa, dan apa yang berlaku jika mereka tidak bertindak?

SLA Tugasan Lead adalah contoh yang baik. Lead yang ditugaskan kepada wakil jualan tidak sepatutnya tersimpan tanpa disentuh kerana wakil jualan sedang mesyuarat atau peraturan penghalaan tidak jelas. Proses perlu mentakrifkan masa tugasan, kriteria penerimaan, eskalasi, dan tugasan semula.

Reka bentuk proses juga menghalang hutang serah tugas selepas jualan. Jika peralihan jualan-ke-CS bergantung pada wakil jualan menulis mesej Slack yang bertimbang rasa, serah tugas akan merosot semasa tempoh sibuk. Serah tugas jualan-CS atau aliran kerja closed-won yang berstruktur perlu menjadikan konteks pelanggan wajib tidak dapat dielakkan.

Lapisan 4: Model data dan tadbir urus sistem

Tadbir urus data adalah tempat banyak pasukan RevOps sama ada mendapat kepercayaan atau kehilangannya.

Sistem hasil memerlukan peraturan yang jelas untuk:

• Medan wajib mengikut peringkat
• Definisi medan
• Sistem mana yang memiliki setiap medan
• Peranan mana yang boleh mengedit medan kritikal
• Cara pendua dikendalikan
• Cara data pengayaan diterima
• Cara ralat integrasi dipantau
• Cara perubahan sistem diminta dan diluluskan

Ini bukan birokrasi untuk kepentingan diri sendiri. Ia melindungi lapisan ramalan, atribusi, penghalaan, dan pelaporan daripada kereputan senyap.

Penyelidikan Forrester mengenai penyelarasan teknologi RevOps menghujahkan bahawa organisasi B2B yang beralih kepada RevOps memerlukan penyelarasan berterusan merentasi teknologi pemasaran, jualan, dan customer success. Itulah tepatnya apa yang dikendalikan oleh lapisan ini. CRM, platform automasi pemasaran, alat customer success, sistem pembilan, penyedia pengayaan, dan lapisan BI tidak boleh masing-masing mentakrifkan kebenaran pelanggan secara berasingan.

Sekurang-kurangnya, RevOps perlu mengekalkan kamus data hasil. Ia perlu merangkumi nama medan, definisi, sistem pemilik, pemilik, peringkat wajib, nilai dibenarkan, dan laporan hiliran yang terjejas.

Lapisan 5: Metrik dan pelaporan

Metrik perlu memberitahu pemimpin apa yang perlu dibaiki seterusnya.

Lapisan metrik RevOps perlu memisahkan tiga pandangan pelaporan:

Dashboard eksekutif perlu kekal kecil. Pipeline dijana, penukaran mengikut peringkat, liputan pipeline, ketepatan ramalan, kadar kemenangan, kitaran jualan, pengekalan, pengembangan, dan varians pelan hasil biasanya sudah mencukupi.

Dashboard kerja RevOps boleh lebih mendalam. Ia perlu merangkumi kegagalan penghalaan, penuaan lead, pelanggaran SLA, kelengkapan medan, kadar pendua, peluang basi, penukaran sumber, dan kelengkapan serah tugas.

Di sinilah Pipeline berbanding Ramalan penting. Pipeline ialah inventori hasil berpotensi. Ramalan ialah hasil hasil yang dijangka sepanjang tempoh. RevOps memerlukan kedua-duanya, tetapi ia menjawab soalan operasi yang berbeza.

CIO Dive merumuskan penyelidikan Gartner yang menunjukkan kurang daripada separuh pemimpin jualan dan jurujual mempunyai keyakinan tinggi terhadap ketepatan ramalan. Itu bukan sekadar masalah pertimbangan jualan. Ia biasanya masalah model data, disiplin peringkat, dan irama pemeriksaan.

Lapisan 6: Irama dan akauntabiliti

Irama tidak sama dengan mesyuarat.

Mesyuarat adalah acara kalendar. Irama adalah sistem keputusan yang boleh diulang dengan input, pemilik, output, dan susulan.

RevOps perlu membantu mentakrifkan irama hasil teras:

Setiap irama memerlukan pemilik keputusan. Jika tidak, mesyuarat menjadi perbincangan tanpa perubahan operasi.

Pasukan RevOps yang paling kukuh tegas mengenai tujuan mesyuarat. Semakan ramalan bukan tempat untuk membersihkan medan CRM. Semakan funnel bulanan bukan tempat untuk memeriksa deal tersekat satu wakil jualan. Tadbir urus sistem bukan tempat untuk membincangkan semula strategi syarikat.

Susunan pelaksanaan

Jika asas RevOps anda lemah, baikinya mengikut susunan ini.

Pertama: takrifkan kitaran hayat. Bersetuju dengan peringkat daripada lead hingga pembaharuan. Tulis kriteria kemasukan dan keluar. Hapuskan peringkat pendua atau kabur. Jadikan definisi peringkat kelihatan.

Kedua: kuatkuasakan serah tugas. Pilih serah tugas dengan geseran tertinggi dan takrifkan pemilikan, SLA, medan wajib, dan eskalasi. Biasanya ini bermaksud tugasan lead, MQL kepada SQL, penciptaan peluang, dan closed-won kepada onboarding.

Ketiga: bersihkan lapisan pelaporan. Bina dashboard bersama yang berguna dan paling kecil daripada definisi yang dipersetujui. Jangan mulakan dengan dua puluh carta. Mulakan dengan metrik yang menggerakkan keputusan mingguan dan bulanan.

Keempat: tadbir perubahan sistem. Kunci medan kritikal, dokumenkan sumber kebenaran, dan cipta proses permintaan perubahan. Kebanyakan kereputan data bermula dengan perubahan tempatan yang berniat baik.

Kelima: tambah baik irama. Bina semula mesyuarat di sekeliling keputusan. Setiap mesyuarat hasil berulang perlu mempunyai pemilik, pakej data, jenis keputusan, dan log susulan.

Rangka kerja RevOps minimum boleh guna

Anda tidak memerlukan model operasi peringkat enterprise untuk mula menggunakan rangka kerja ini. Syarikat B2B 60 orang boleh menggunakan versi yang lebih ringan dalam beberapa minggu.

Versi minimum boleh guna mempunyai enam artifak:

Ini sudah mencukupi untuk mendedahkan kebanyakan jurang operasi. Jika peta kitaran hayat tidak jelas, jangan mulakan dengan dashboard. Jika jadual serah tugas kehilangan pemilik, jangan mulakan dengan automasi. Jika medan wajib terlalu banyak, baiki proses penangkapan sebelum meminta wakil jualan untuk lebih banyak kemas kini.

Pusingan pertama yang berguna boleh dibina daripada rekod sebenar. Ambil sepuluh lead terkini, sepuluh peluang, lima deal closed-won, dan lima pelanggan churn atau berisiko pembaharuan. Bagi setiap satu, tanya sama ada peringkat, pemilik, data wajib, tindakan seterusnya, dan sumber pelaporan jelas. Di mana jawapannya tidak, rangka kerja memerlukan kerja.

Audit berasaskan rekod ini mengekalkan kejujuran rangka kerja. Pemimpin boleh berdebat tentang rajah proses selama berjam-jam, tetapi rekod sebenar menunjukkan di mana model operasi sebenarnya rosak: medan hilang, pemilik tidak jelas, peringkat basi, dan serah tugas yang bergantung pada ingatan.

Gunakan penemuan untuk menyusun keutamaan pembaikan mengikut risiko hasil.

Contoh: mengaplikasikan rangka kerja

Bayangkan sebuah syarikat dengan jumlah lead yang kukuh tetapi penciptaan pipeline yang lemah.

Pada mulanya, perbualan kepimpinan kedengaran seperti konflik pemasaran-jualan. Pemasaran berkata kempen berfungsi. Jualan berkata lead lemah. RevOps tidak sepatutnya bermula dengan bertanya siapa yang betul. Ia perlu mengaplikasikan rangka kerja.

Strategi hasil mungkin menunjukkan syarikat beralih ke arah akaun mid-market sementara campuran kempen masih menyasarkan perniagaan kecil. Senibina funnel mungkin menunjukkan kriteria MQL tidak pernah dikemas kini selepas ICP berubah. Reka bentuk proses mungkin menunjukkan lead dihalakan kepada wakil jualan tanpa medan industri wajib. Lapisan data mungkin menunjukkan nilai sumber tidak konsisten merentasi borang. Metrik mungkin menunjukkan jumlah MQL tinggi tetapi penerimaan SQL rendah daripada dua sumber. Irama mungkin menunjukkan tiada semakan funnel bulanan wujud, jadi corak itu kelihatan dalam data tetapi tidak pernah bertukar menjadi keputusan.

Pembaikannya bukan satu dashboard. Pembaikannya ialah satu urutan: kemas kini peraturan kesesuaian ICP, tukar input penghalaan, takrifkan sebab penolakan, bina semula pelaporan sumber, dan tambah semakan funnel bulanan di mana pemasaran dan jualan membuat satu keputusan operasi daripada data yang sama.

Itulah cara rangka kerja perlu berfungsi. Ia menukar aduan menjadi diagnosis operasi.

Kesilapan biasa

Bermula dengan dashboard. Dashboard menggoda kerana ia mencipta output yang kelihatan. Tetapi jika kitaran hayat, medan, dan definisi salah, dashboard hanya menjadikan kekeliruan lebih menarik.

Mengautomasikan proses yang rosak. Automasi perlu menguatkuasakan aliran kerja yang baik, bukan menyembunyikan yang buruk. Jika tiada siapa bersetuju apa yang dikira sebagai SQL, menghalakan SQL dengan lebih pantas tidak akan membaiki pertikaian kualiti.

Menambah medan tanpa tadbir urus. Setiap medan baharu mencipta kos penyelenggaraan. Jika tiada siapa memiliki definisi dan peraturan kelengkapan, medan itu akan menjadi tidak boleh dipercayai.

Mengelirukan mesyuarat dengan irama. Lebih banyak mesyuarat tidak mencipta disiplin operasi. Irama yang baik mempunyai lebih sedikit mesyuarat dengan keputusan yang lebih jelas.

Menjadikan RevOps baris tiket. Jika RevOps menghabiskan semua masanya bertindak balas terhadap permintaan laporan dan perubahan medan, ia tidak dapat menambah baik sistem. Simpan kapasiti untuk kerja proses dan data yang proaktif.

Soalan Lazim

Apakah rangka kerja Revenue Operations?

Rangka kerja Revenue Operations ialah model berstruktur untuk menjalankan keseluruhan sistem hasil. Ia mentakrifkan lapisan yang perlu ditadbir oleh RevOps: strategi, senibina funnel, proses, data, sistem, metrik, irama, dan akauntabiliti.

Apa yang perlu dibaiki dahulu oleh RevOps?

Baiki definisi kitaran hayat dahulu. Kemudian baiki serah tugas dan SLA. Dashboard dan automasi perlu datang selepas syarikat bersetuju bagaimana rekod bergerak melalui kitaran hayat hasil.

Siapa memiliki rangka kerja RevOps?

RevOps memiliki rangka kerja operasi, tetapi kepimpinan memiliki strategi. CRO, CEO, pemimpin kewangan, pemimpin pemasaran, pemimpin jualan, dan ketua CS mesti bersetuju dengan model pertumbuhan yang dioperasikan oleh RevOps.

Berapa kerap rangka kerja perlu disemak?

Semak rangka kerja setiap suku tahun, dan pada bila-bila masa syarikat menukar ICP, tumpuan segmen, harga, pergerakan jualan, model customer success, atau alat hasil utama.

Ketahui lebih lanjut

• Apakah Revenue Operations?
• Metrik RevOps
• Struktur Pasukan RevOps
• Ketepatan Ramalan
• RevOps sebagai Perekat Penjajaran