90 Hari Pertama dalam RevOps: Playbook Praktikal untuk Operator Hasil Baharu

90 hari pertama dalam RevOps bukan untuk membina semula segalanya.

Ia adalah untuk mempelajari cara sistem hasil sebenarnya berfungsi, menemui punca terbesar seretan operasi, menstabilkan serah tugas paling berisiko, dan mendapat kepercayaan yang mencukupi untuk mengubah sistem itu secara sengaja. Jika anda masih memutuskan bila untuk mengupah RevOps, baca itu dahulu; playbook ini menganggap orang yang diupah sudah berada dalam jawatan.

Pemimpin RevOps baharu sering gagal dengan bergerak terlalu pantas ke arah alat atau dashboard, melompat ke dalam keputusan bina berbanding beli sebelum masalah operasi jelas. Pendekatan yang lebih baik ialah diagnosis dahulu, pembaikan tertumpu kedua, roadmap ketiga.

Gunakan playbook ini bersama Rangka Kerja Revenue Operations. Rangka kerja itu memberi anda lapisan operasi. 90 hari pertama memberitahu anda bagaimana untuk memasuki sistem tanpa mencipta lebih banyak kekacauan.

Panduan RevOps oleh Gartner membingkaikan RevOps sebagai model hujung-ke-hujung merentasi orang, proses, dan teknologi. Itulah sebabnya 90 hari pertama tidak sepatutnya bermula dengan pembinaan semula alat. Tugasnya ialah memahami bagaimana lapisan tersebut benar-benar berkelakuan di dalam syarikat.

Fakta operasi utama

• 90 hari pertama perlu mendiagnosis sistem hasil sebelum mengubahnya: rekod, mesyuarat, serah tugas, definisi, alat, dan kepercayaan pelaporan.
• Bulan pertama perlu memetakan realiti. Bulan kedua perlu menstabilkan aliran kerja berisiko paling tinggi. Bulan ketiga perlu menukar bukti kepada roadmap yang boleh disokong pemimpin.
• Elakkan pembinaan semula besar terlalu awal melainkan aliran kerja secara aktif merosakkan hasil, serah tugas pelanggan, ramalan, atau pematuhan.
• Output 90 hari terbaik bukan senarai tertunggak yang panjang. Ia adalah roadmap operasi ringkas dengan trade-off yang jelas, permintaan yang dijeda, dan pembaikan pertama yang boleh diukur.

Sebelum hari pertama: dapatkan mandat yang jelas

Sebelum bermula, jelaskan tiga perkara dengan pengurus pengambilan atau penaja eksekutif:

1. Masalah apa yang peranan ini diupah untuk selesaikan?
2. Keputusan mana yang boleh dibuat RevOps tanpa eskalasi?
3. Fungsi mana yang berada dalam skop: pemasaran, jualan, CS, kewangan, sistem, atau semuanya?

Jika jawapannya kabur, kiriman pertama anda ialah Piagam RevOps. Tanpa piagam, 90 hari pertama akan tertarik ke dalam laporan, tiket, dan permintaan mendesak sebelum masalah operasi difahami.

Model tanggungjawab RevOps oleh Forrester menonjolkan keluasan tanggungjawab merentasi operasi pemasaran, jualan, rakan kongsi, dan kejayaan pelanggan. Pemimpin RevOps baharu perlu tahu tanggungjawab mana yang benar-benar berada dalam skop.

Papan skor 90 hari pertama

Gunakan papan skor untuk kekal fokus.

Papan skor ini menghalang 90 hari pertama daripada bertukar menjadi koleksi kemenangan ad hoc. Pembaikan pantas berguna, tetapi hanya jika ia menyokong model operasi yang lebih jelas.

Hari 1 hingga 30: petakan realiti

Bulan pertama anda perlu menjawab satu soalan: bagaimana hasil sebenarnya bergerak melalui syarikat ini?

Jangan mulakan dengan slaid proses rasmi. Mulakan dengan rekod, mesyuarat, dan temu bual.

Semak:

• Penangkapan dan penghalaan lead
• Definisi MQL dan SQL
• Kriteria peringkat peluang
• Kategori ramalan
• Serah tugas closed-won
• Proses pembaharuan dan pengembangan
• Kelengkapan medan CRM
• Definisi dashboard
• Mesyuarat operasi semasa

Temu bual pemasaran, SDR, AE, pengurus jualan, CS, kewangan, dan eksekutif. Tanya di mana sistem menjadi perlahan, laporan mana yang tidak dipercayai, dan kerja apa yang berlaku di luar CRM.

Bandingkan apa yang orang katakan dengan apa yang ditunjukkan data.

Soalan temu bual untuk ditanya

Gunakan temu bual untuk mencari ketidakpadanan antara proses rasmi dan tingkah laku sebenar.

Tanya pemasaran:

• Sumber mana yang mencipta lead yang benar-benar diterima jualan?
• Peraturan kelayakan mana yang paling banyak diperdebatkan?
• Laporan atribusi mana yang tidak dipercayai?

Tanya jualan:

• Jenis lead mana yang paling mudah dikendalikan?
• Medan CRM mana yang terasa berguna, dan mana yang terasa seperti teater?
• Di mana deal tersekat sebelum semakan ramalan?

Tanya kejayaan pelanggan:

• Konteks apa yang tiada selepas closed-won?
• Janji mana yang mencipta geseran onboarding?
• Sebab churn mana yang perlu dimaklum balaskan kepada kelayakan?

Tanya kewangan:

• Angka hasil mana yang memerlukan penyesuaian manual?
• Medan CRM mana yang menjejaskan keyakinan perancangan?
• Andaian ramalan mana yang paling lemah?

Intinya bukan mengumpul aduan. Intinya ialah mengenal pasti jurang operasi yang muncul merentasi pelbagai pasukan.

Audit 30 hari pertama

Ambil sampel rekod kecil:

Audit ini biasanya lebih berguna berbanding gelung temu bual yang panjang. Rekod sebenar mendedahkan sama ada sistem berfungsi apabila tiada siapa memerhati.

Kiriman menjelang hari 30:

• Peta lifecycle hasil
• Peta sumber kebenaran
• Inventori serah tugas
• Audit kepercayaan dashboard
• Garis dasar kualiti data
• Senarai hamparan bayang-bayang dan penyelesaian manual

Hari 31 hingga 60: stabilkan serah tugas berisiko paling tinggi

Jangan cuba membaiki setiap aliran kerja.

Pilih dua atau tiga serah tugas di mana kebocoran kelihatan:

• Lead ditugaskan tetapi tidak diterima
• MQL diterima tetapi tidak ditukar
• Peringkat peluang berubah tanpa bukti
• Deal closed-won diserahkan kepada CS tanpa konteks
• Risiko pembaharuan tidak dieskalasi cukup awal

Bagi setiap serah tugas, tentukan:

• Pemilik
• Kriteria kemasukan
• Data wajib
• SLA
• Laluan eskalasi
• Pandangan dashboard

Proses Serah Tugas MQL kepada SQL dan Proses Serah Tugas Closed-Won kepada Onboarded adalah corak yang berguna.

Apa yang perlu dibaiki dahulu

Pilih serah tugas mengikut risiko hasil, bukan bunyi bising politik.

Pembaikan pertama perlu cukup kelihatan untuk membina kepercayaan tetapi cukup sempit untuk diselesaikan.

Cara mengelak daripada menjadi baris gilir permintaan

30 hari pertengahan adalah ketika pemimpin RevOps baharu paling berkemungkinan tertimbun.

Orang mendapati anda dapat membaiki laporan, medan, import, automasi, dashboard, peraturan penghalaan, dan soalan proses. Setiap permintaan kedengaran munasabah. Jika anda menerima semuanya, peranan itu menjadi baris gilir sebelum ia menjadi fungsi.

Cipta tiga laluan:

Ini bukan tentang tidak membantu. Ia adalah tentang melindungi kapasiti untuk kerja yang RevOps diupah untuk lakukan.

Hari 61 hingga 90: bina roadmap operasi

Menjelang bulan ketiga, anda perlu mempunyai bukti yang mencukupi untuk mencadangkan roadmap praktikal.

Roadmap tidak sepatutnya menjadi senarai keinginan sistem yang besar. Ia perlu mengaitkan masalah operasi dengan hasil hasil.

Gunakan Rangka Kerja Revenue Operations untuk menyusun roadmap mengikut proses, data, sistem, metrik, irama, dan tadbir urus.

Rupa roadmap 90 hari yang sepatutnya

Roadmap perlu cukup khusus untuk dibiayai dan disusun.

Elakkan item luas seperti "perbaiki pelaporan" atau "bersihkan CRM." Tulis kerja operasi:

• Takrifkan peringkat MQL, SQL, peluang, closed-won, onboarded, pembaharuan, dan pengembangan.
• Tambah sebab penolakan kepada aliran kerja MQL dan semak setiap bulan.
• Cipta medan wajib serah tugas closed-won sebelum permulaan onboarding.
• Kunci medan sumber dan dokumenkan peraturan atribusi.
• Bina satu dashboard eksekutif dengan definisi yang ditadbir urus.
• Cipta semakan funnel bulanan dan irama tadbir urus ramalan.

Setiap item roadmap perlu mempunyai pemilik, kesan perniagaan jangkaan, kebergantungan, dan tetingkap penyiapan sasaran.

Apa yang tidak patut dilakukan dalam 90 hari pertama

Jangan bina semula CRM serta-merta. Anda mungkin memerlukannya kemudian, tetapi pembinaan semula sebelum diagnosis biasanya mencipta semula kekeliruan proses yang sama dalam antara muka yang lebih bersih.

Jangan lancarkan dashboard yang tiada siapa dapat bertindak ke atasnya. Dashboard perlu menyokong keputusan. Mulakan dengan keputusan yang sudah perlu dibuat pemimpin.

Jangan terima setiap permintaan. Pemimpin RevOps baharu boleh menjadi baris gilir tiket dengan cepat. Asingkan pembaikan mendesak daripada kerja struktur.

Jangan ubah definisi secara senyap. Definisi lifecycle dan ramalan menjejaskan pasukan secara politik. Jadikan perubahan kelihatan dan jelaskan sebab operasinya.

Jangan automasikan secara berlebihan. Automasi perlu menguatkuasakan aliran kerja yang jelas. Jika peraturan itu tidak dipersetujui, automasi akan menyukarkan perselisihan itu untuk diperiksa.

Kiriman 90 hari pertama

Menjelang akhir 90 hari, hasilkan:

• Peta lifecycle hasil
• Senarai risiko serah tugas
• Garis dasar kualiti data
• Audit kepercayaan dashboard
• Peta pemilikan sistem
• Draf piagam RevOps
• Roadmap penambahbaikan 90 hari
• Cadangan hak keputusan
• Irama hasil operasi pertama yang berfungsi

Kiriman ini mencipta konteks yang dikongsi. Ia juga menghalang RevOps daripada menjadi fungsi kabur yang disokong semua orang secara teori tetapi diabaikan secara praktikal.

Cara memaklumkan kemajuan

Eksekutif tidak memerlukan senarai berjalan bagi setiap medan yang dibersihkan atau laporan yang diselaraskan.

Laporkan kemajuan dalam istilah operasi:

• Kebocoran hasil mana yang ditemui?
• Serah tugas mana yang distabilkan?
• Definisi data mana yang kini ditadbir urus?
• Laporan mana yang kini dipercayai?
• Keputusan mana yang boleh dibuat pemimpin dengan lebih pantas?
• Risiko mana yang masih tinggal?

Itulah perbezaan antara "RevOps sibuk" dan "RevOps sedang memperbaiki sistem hasil."

90 hari pertama mengikut peringkat syarikat

Pelan perlu disesuaikan mengikut peringkat.

Pengambilan RevOps pertama di syarikat 40 orang tidak sepatutnya menghabiskan 90 hari membina model tadbir urus enterprise. Pemimpin RevOps di syarikat 400 orang tidak sepatutnya menghabiskan 90 hari hanya membersihkan medan. Sesuaikan kerja dengan kerumitan operasi.

Apa yang perlu ditunjukkan kepada eksekutif pada hari ke-90

Bacaan hari ke-90 tidak sepatutnya menjadi senarai tugas yang diselesaikan.

Gunakan struktur ini:

1. Peta sistem hasil keadaan semasa.
2. Lima kebocoran hasil teratas yang ditemui.
3. Garis dasar kualiti data.
4. Serah tugas yang distabilkan.
5. Keputusan yang dibuat atau tertunggak.
6. Risiko yang masih memerlukan sokongan eksekutif.
7. Roadmap 90 hari seterusnya.

Kekalkan cerita itu praktikal. Pemimpin perlu keluar dengan mengetahui apa yang kini dapat dilakukan sistem hasil, apa yang masih tidak boleh dipercayai, dan keputusan mana yang memerlukan bantuan mereka.

Kesilapan biasa 90 hari pertama

Terlalu fokus kepada alat. Alat penting, tetapi susun atur pentadbir baharu tidak membaiki definisi lifecycle yang tidak jelas.

Cuba memuaskan setiap pihak berkepentingan. RevOps bersifat silang fungsi, tetapi ia tidak boleh menjadi pasukan pelaporan peribadi untuk setiap pemimpin.

Mengelak keputusan politik. Definisi MQL, kategori ramalan, dan medan wajib bersifat politik kerana ia mengubah akauntabiliti. Mengelak keputusan tersebut mengekalkan sistem itu lemah.

Melangkau kewangan. Kewangan sering tahu data hasil mana yang tidak dipercayai. Libatkan kewangan dalam audit lebih awal.

Kurang komunikasi trade-off. Jika RevOps mengurangkan keutamaan permintaan untuk membaiki isu sistem yang lebih besar, jelaskan trade-off itu. Kesenyapan kelihatan seperti perkhidmatan yang perlahan.

Cara memutuskan apa yang menunggu

Sesetengah kerja perlu menunggu sehingga selepas 90 hari pertama:

• Pembinaan semula CRM yang besar
• Penyatuan tumpukan teknologi penuh
• Pemodelan atribusi lanjutan
• Pemarkahan ramalan AI
• Program automasi yang luas
• Reka bentuk semula pampasan yang kompleks

Projek tersebut mungkin penting, tetapi ia bergantung kepada definisi yang dipercayai dan pemahaman keadaan semasa. Memulakannya terlalu awal mencipta kerja semula yang mahal.

Gunakan 90 hari pertama untuk mendapatkan hak melakukan kerja yang lebih besar. Apabila pemimpin melihat bahawa RevOps dapat mendiagnosis sistem, menstabilkan serah tugas, dan mencipta pelaporan yang dipercayai, mereka lebih berkemungkinan menyokong roadmap yang lebih mendalam.

Disiplinnya mudah: baiki kebocoran yang mengherotkan keputusan hasil dahulu. Kemudian bina semula seni bina yang lebih besar.

Penyusunan itu juga melindungi kredibiliti. Pasukan lebih bersedia menerima perubahan proses yang lebih besar selepas mereka melihat RevOps menyelesaikan kesakitan operasi yang kelihatan dalam aliran kerja hasil semasa terlebih dahulu, dengan bukti.

Kepercayaan berkembang dari situ.

Kesimpulan cara memutuskan apa yang menunggu

90 hari pertama perlu mencipta kepercayaan sebelum skala. Pemilik RevOps baharu perlu memeriksa sistem hasil sebenar, menstabilkan serah tugas berisiko paling tinggi, mendokumenkan hak keputusan, dan membina roadmap yang boleh disokong pemimpin.

Matlamatnya bukan pembinaan semula penuh. Matlamatnya ialah membuktikan bahawa syarikat dapat menjalankan kerja hasil daripada bukti yang dikongsi dan bukannya perdebatan berulang. Sebaik sahaja kepercayaan itu wujud, sistem yang lebih besar, automasi, atribusi, dan kerja ramalan menjadi lebih mudah dijustifikasikan.

Itulah pencapaian onboarding yang sebenar.

Jika syarikat mempercayai diagnosis dan pembaikan pertama, roadmap seterusnya mempunyai peluang penerimaan yang jauh lebih baik.

Rentak operasi mingguan

90 hari pertama perlu mempunyai rentak mingguan yang mudah. Tanpanya, penemuan bertukar menjadi perbualan pihak berkepentingan yang rawak dan pemilik RevOps baharu menjadi reaktif terlalu awal.

Rentak ini memberikan pemilik baharu satu laluan tanpa berpura-pura setiap syarikat mempunyai masalah yang sama. Output mingguan boleh berubah, tetapi setiap minggu perlu mencipta artifak yang boleh diperiksa pemimpin.

Pakej keputusan hari ke-90

Pembentangan hari ke-90 tidak sepatutnya menjadi laporan aktiviti yang panjang.

Ia perlu menjawab lima keputusan:

1. Masalah operasi mana yang paling banyak membebankan kos kepada syarikat?
2. Definisi atau serah tugas mana yang kini ditadbir urus?
3. Metrik mana yang boleh dipercayai kepimpinan sekarang?
4. Kerja mana yang memerlukan trade-off eksekutif suku seterusnya?
5. Permintaan mana yang perlu dihentikan atau ditangguhkan oleh RevOps?

Jika pembentangan itu tidak membawa kepada keputusan, 90 hari pertama kekal terlalu deskriptif. RevOps perlu meninggalkan hari ke-90 dengan mandat yang lebih jelas, roadmap yang disusun mengikut kedudukan, dan kebenaran untuk melindungi sistem operasi daripada kerja bernilai rendah.

Soalan Lazim

Apa yang patut dilakukan pemimpin RevOps baharu terlebih dahulu?

Petakan proses hasil semasa dan bandingkan proses rasmi dengan rekod, laporan, dan tingkah laku pasukan sebenar. Jangan mulakan dengan alat.

Apakah kemenangan RevOps pertama yang terbaik?

Baiki serah tugas yang kelihatan bocor hasil, seperti penugasan lead, penerimaan MQL, atau kelengkapan serah tugas closed-won.

Patutkah 90 hari pertama merangkumi pembersihan CRM?

Hanya pembersihan yang mencukupi untuk menstabilkan aliran kerja kritikal. Pembersihan CRM yang luas perlu mengikuti tadbir urus medan dan perubahan proses, atau data akan merosot semula.

Berapa banyak perubahan yang patut dibuat RevOps dalam 90 hari pertama?

Cukup untuk menstabilkan kebocoran yang jelas dan mendapat kepercayaan. Simpan reka bentuk semula sistem besar untuk selepas audit dan roadmap diterima.

Ketahui lebih lanjut

• Piagam RevOps
• Audit Proses Hasil
• Metrik RevOps
• SLA Penugasan Lead