Model Operasi Penerimaan CRM: Bagaimana RevOps Mencapai Penggunaan yang Boleh Dipercayai
Turn this article into takeaways for your work.
Each assistant summarizes the article only for you and suggests best practices for your work.
Penerimaan CRM tidak diselesaikan dengan memberitahu orang untuk mengemaskini CRM.
Orang menggunakan sistem apabila aliran kerja itu masuk akal, medan itu penting, pengurus memeriksa data, dan sistem memberikan nilai kembali. Mereka mengelakkan sistem apabila medan terasa sewenang-wenangnya, kemasukan data hilang begitu sahaja dalam laporan, dan mesyuarat masih berjalan daripada hamparan (spreadsheet).
Penerimaan adalah masalah reka bentuk operasi. RevOps memperbaikinya dengan menjadikan penggunaan CRM sebahagian daripada cara kerja hasil dilaksanakan, bukan tugasan tambahan selepas kerja sebenar selesai.
Soalan penerimaan yang salah ialah "Bagaimana kita menjadikan pengguna patuh?"
Soalan yang lebih baik ialah "Bagaimana kita menjadikan CRM tempat yang paling mudah dan paling dipercayai untuk melakukan kerja?"
Penyelidikan penjajaran teknologi RevOps oleh Forrester berguna kerana penerimaan bergantung kepada sama ada alatan sepadan dengan aliran kerja hasil. Penyelidikan produktiviti jualan oleh McKinsey turut menunjukkan nilai disiplin operasi yang fokus berbanding pengurusan aktiviti generik.
Fakta operasi utama
- Penerimaan CRM didorong oleh nilai aliran kerja, bukan peringatan log masuk.
- Pengguna mengekalkan data yang diperiksa oleh pengurus dan yang menjadi asas keputusan.
- Medan wajib tanpa pertukaran nilai mencipta kesempurnaan palsu.
- Metrik penerimaan perlu menjejaki kualiti aliran kerja, bukan hanya aktiviti sistem.
- Kemenangan penerimaan paling pantas biasanya datang daripada mengurangkan geseran sebelum menambah peraturan baharu.
Kenapa penerimaan CRM gagal
Kebanyakan masalah penerimaan mempunyai punca yang rasional.
Pengguna mengelakkan CRM apabila:
- Medan diwajibkan sebelum jawapan boleh diketahui
- Pengurus tidak memeriksa data
- Laporan tidak dipercayai
- Sistem lebih perlahan daripada kerja sebenar
- Kemasukan data tidak membantu pengguna
- Rekod pendua mencipta kekeliruan
- Automasi mencipta gangguan
- Definisi berubah tanpa penjelasan
- Mesyuarat masih berjalan daripada hamparan
- Pengguna diminta memberikan data yang tidak digunakan oleh sesiapa
Diagnosis biasa ialah "pengguna tidak berdisiplin." Diagnosis yang lebih baik ialah "sistem operasi tidak memberikan pengguna sebab untuk mempercayai CRM."
Apabila penerimaan lemah, RevOps perlu memeriksa aliran kerja sebelum menyalahkan pengguna.
Penerimaan bergantung kepada pertukaran nilai
Setiap aliran kerja CRM mencipta pertukaran nilai.
Pengguna memberikan data. Sistem perlu memberikan sesuatu kembali: penghalaan, keutamaan, serah tugas yang lebih bersih, bimbingan pengurus yang lebih baik, kurang soalan berulang, kelulusan yang lebih pantas, perbualan ramalan yang lebih jelas, atau perancangan pembaharuan yang lebih mudah.
Jika pengguna memberikan data dan hanya menerima beban pentadbiran, penerimaan akan kekal lemah.
Contoh:
- Wakil jualan mengemaskini langkah seterusnya kerana pengurus memeriksanya dalam semakan pipeline.
- Pengurus mengemaskini kategori ramalan kerana finance dan kepimpinan menggunakan pakej ramalan yang sama.
- Customer success mengisi medan kesihatan kerana risiko pembaharuan disemak daripada medan tersebut.
- Pemasaran mengekalkan data sumber kerana keputusan atribusi menggunakannya.
- Jualan memasukkan konteks serah tugas kerana customer success menggunakannya pada panggilan onboarding pertama.
Penerimaan meningkat apabila CRM menjadi tempat di mana keputusan berlaku.
Model penerimaan RevOps
Model praktikal mempunyai enam bahagian.
| Bahagian | Maksud | Mod kegagalan |
|---|---|---|
| Kesesuaian aliran kerja | Langkah CRM sepadan dengan bagaimana kerja sebenarnya berlaku | Pengguna mengekalkan sistem sampingan |
| Disiplin medan | Data wajib diberi masa yang tepat dan berguna | Pengguna memasukkan nilai sementara sahaja |
| Pemeriksaan pengurus | Pengurus menggunakan data CRM dalam mesyuarat irama | Pengguna menganggap kemasukan data sebagai pilihan |
| Gelung maklum balas | Pengguna boleh melaporkan geseran dan melihat pembaikan | Jalan pintas menjadi normal |
| Kepercayaan pelaporan | Dashboard mencerminkan definisi yang difahami orang | Pemimpin membina semula laporan dalam hamparan |
| Pulangan nilai | Sistem membantu pengguna melakukan kerja mereka | CRM terasa seperti pelaporan sehala |
Jika mana-mana bahagian hilang, penerimaan melemah.
Reka bentuk medan berdasarkan keputusan
Medan perlu wujud kerana satu keputusan, serah tugas, aliran kerja, atau laporan bergantung kepadanya.
Sebelum mewajibkan satu medan, tanya:
- Siapa yang menggunakan data ini?
- Bila pengguna boleh mengetahui jawapannya?
- Apa yang berlaku jika medan itu kosong?
- Apa yang berlaku jika pengguna memasukkan data palsu?
- Laporan atau automasi mana yang bergantung kepadanya?
- Siapa yang memiliki definisi tersebut?
- Bagaimana pengurus akan memeriksanya?
Ini mengaitkan penerimaan CRM dengan required fields vs useful fields dan CRM field governance.
Langkah penerimaan terbaik selalunya ialah membuang medan yang sudah tidak lagi penting.
Tetapkan masa medan wajib mengikut aliran kerja
Medan wajib boleh memperbaiki penerimaan apabila ia muncul pada masa yang betul.
Ia merosakkan penerimaan apabila ia muncul terlalu awal.
| Medan | Masa yang lemah | Masa yang lebih baik |
|---|---|---|
| Status procurement | Diwajibkan semasa penciptaan opportunity | Diwajibkan sebelum cadangan atau commit |
| Risiko pelaksanaan | Diwajibkan semasa penemuan (discovery) | Diwajibkan sebelum closed-won |
| Sebab closed-lost | Diwajibkan semasa deal masih terbuka | Diwajibkan semasa menutup sebagai hilang |
| Champion dikenal pasti | Diwajibkan sebelum panggilan pertama | Diwajibkan sebelum pergerakan peringkat lewat |
| Risiko pembaharuan | Diwajibkan untuk setiap rekod pelanggan | Diwajibkan untuk akaun dalam tempoh pembaharuan |
Masa yang salah mencipta data palsu. Pengguna mengisi medan itu kerana sistem menghalang mereka, bukan kerana mereka mengetahui jawapannya.
Libatkan pengurus dalam gelung
Tingkah laku pengurus mendorong penerimaan lebih daripada latihan.
Jika pengurus menjalankan semakan deal daripada hamparan, wakil jualan akan mengekalkan hamparan. Jika pengurus memeriksa rekod CRM semasa semakan, wakil jualan akan mengekalkan rekod CRM.
Pemeriksaan pengurus perlu fokus kepada medan yang penting:
- Langkah seterusnya
- Tarikh tutup
- Bukti peringkat
- Kategori ramalan
- Proses keputusan
- Halangan yang diketahui
- Kesediaan serah tugas
- Risiko pembaharuan
- Status pelan tindakan bersama
Jangan minta pengurus memeriksa segala-galanya. Pilih data yang menyokong irama operasi.
Jadikan mesyuarat menguatkuasakan model operasi
Penerimaan berubah apabila mesyuarat berubah.
Jika mesyuarat pipeline meminta data daripada CRM, CRM menjadi berguna. Jika panggilan ramalan menggunakan helaian berasingan, pengguna belajar bahawa CRM adalah pilihan sahaja. Jika serah tugas closed-won berlaku dalam Slack, medan serah tugas hanya menjadi teater.
Reka bentuk mesyuarat perlu menjadikan penggunaan CRM semula jadi:
| Mesyuarat | Tingkah laku CRM yang perlu dikukuhkan |
|---|---|
| Semakan pipeline | Langkah seterusnya semasa, tarikh tutup, bukti peringkat |
| Panggilan ramalan | Kategori ramalan, risiko, bukti commit |
| Semakan kempen | Kualiti sumber, penukaran, amaran atribusi |
| Semakan serah tugas | Konteks closed-won dan risiko pelaksanaan |
| Semakan pembaharuan | Kesihatan, penggunaan, tarikh pembaharuan, isyarat pengembangan |
Inilah sebabnya penerimaan tergolong dalam model operasi, bukan hanya dalam latihan.
Kurangkan geseran sebelum menambah peringatan
Peringatan bukan strategi.
Jika pengguna mengabaikan kemasukan CRM, periksa geseran:
- Terlalu banyak medan
- Susun atur halaman yang perlahan
- Rekod pendua
- Nilai yang mengelirukan
- Medan diwajibkan pada peringkat yang salah
- Automasi mencipta tugasan yang tidak relevan
- Data sudah ditangkap di tempat lain
- Pengalaman mudah alih terlalu sukar
- Laporan yang tidak sepadan dengan soalan pengurus
- Carian yang menyukarkan rekod dijumpai
Baiki geseran sebelum menambah lebih banyak dorongan. Peringatan untuk melakukan aliran kerja yang buruk tidak memperbaiki penerimaan.
Diagnosis jalan pintas
Jalan pintas bukan sekadar penentangan pengguna. Ia adalah maklum balas produk.
Jalan pintas biasa:
- Hamparan pengurus
- Utas serah tugas Slack
- Senarai tugas peribadi
- Nota sampingan di luar CRM
- Penjejak wakil jualan tersuai
- Laporan yang dibina semula secara manual
- Akaun pendua digunakan sebagai rekod bayangan
Setiap jalan pintas adalah petunjuk.
| Jalan pintas | Apa yang mungkin dimaksudkan |
|---|---|
| Hamparan pengurus | Laporan CRM tidak menjawab soalan semakan |
| Serah tugas Slack | Medan serah tugas CRM terlalu lemah atau terlalu perlahan |
| Senarai tugas peribadi | Aliran kerja tugasan CRM mencipta gangguan |
| Pembinaan semula laporan manual | Definisi data tidak dipercayai |
| Akaun bayangan | Peraturan pemilikan atau hierarki tidak jelas |
RevOps tidak sepatutnya melarang jalan pintas sebelum memahami kenapa ia wujud.
Ukur penerimaan berdasarkan tingkah laku, bukan log masuk
Kiraan log masuk adalah metrik penerimaan yang lemah.
Isyarat yang lebih baik:
- Penyempurnaan medan kritikal mengikut peringkat
- Kemasukan opportunity sebelum panggilan ramalan
- Rekod yang disemak pengurus
- Kadar tarikh tutup yang usang
- Kelengkapan langkah seterusnya
- Kelengkapan serah tugas closed-won
- Kadar penciptaan pendua
- Penggunaan laporan dalam mesyuarat irama
- Penggantian hamparan
- Pengurangan permintaan konteks Slack
Penerimaan perlu diukur berdasarkan aliran kerja yang penting. Seorang pengguna boleh log masuk setiap hari dan masih mengelakkan data yang menjadikan proses hasil berfungsi.
Bina kad skor penerimaan
Kad skor penerimaan perlu mengaitkan tingkah laku sistem dengan hasil operasi.
| Aliran kerja | Isyarat penerimaan | Isyarat lemah |
|---|---|---|
| Semakan pipeline | Opportunity dikemaskini sebelum semakan | Pengurus meminta kemasukan berasingan |
| Ramalan | Deal commit mempunyai bukti semasa | Kategori ramalan berubah di luar CRM |
| Serah tugas | Medan closed-won digunakan customer success | CS bertanya soalan yang sama dalam Slack |
| Atribusi | Medan sumber lengkap dan dipercayai | Semakan kempen bermula dengan pertikaian data |
| Pembaharuan | Medan kesihatan dan pembaharuan semasa | Risiko pembaharuan dijumpai di luar CRM |
Kad skor ini perlu disemak bersama pengurus, bukan disembunyikan dalam dashboard RevOps.
Tambah kawalan operasi
Penerimaan bertambah baik apabila sistem mempunyai kawalan yang sesuai dengan aliran kerja.
Kawalan itu perlu cukup kukuh untuk membentuk tingkah laku tetapi tidak terlalu berat sehingga pengguna mencipta jalan pintas.
| Kawalan | Apa yang ia lakukan | Risiko penerimaan |
|---|---|---|
| Medan wajib | Menghalang aliran kerja sehingga data wujud | Data palsu jika masa tidak tepat |
| Pemeriksaan pengurus | Menjadikan data jelas dilihat dalam semakan | Lemah jika pengurus tidak konsisten |
| Bendera dashboard | Menunjukkan rekod yang hilang atau usang | Diabaikan jika tiada mesyuarat menggunakannya |
| Gesaan automasi | Mengingatkan pengguna pada masa yang tepat | Gangguan jika terlalu kerap |
| Barisan pengecualian | Menangkap rekod yang perlu disemak | Tertunggak jika tiada pemilik yang menyemaknya |
| Persaraan medan | Membuang pengumpulan data yang tidak digunakan | Perlahan jika pemilik enggan memadam medan |
RevOps perlu memilih kawalan paling ringan yang mengubah tingkah laku.
Jika pemeriksaan pengurus berkesan, jangan tambah peraturan pengesahan yang keras. Jika bendera laporan berkesan, jangan tambah tetingkap pop timbul. Jika satu medan tidak lagi menyokong keputusan, sarakan ia berbanding melatih pengguna mengabaikannya.
Tentukan kriteria penerimaan aliran kerja
Penerimaan menjadi lebih mudah apabila pengguna tahu apa maksud "selesai."
Untuk setiap aliran kerja, tentukan kriteria penerimaan.
| Aliran kerja | Maksud selesai |
|---|---|
| Kemasukan opportunity | Peringkat, tarikh tutup, jumlah, langkah seterusnya, dan risiko mencerminkan realiti semasa |
| Penyerahan ramalan | Kategori ramalan mempunyai bukti dan semakan pengurus |
| Serah tugas closed-won | Customer success mempunyai konteks yang diperlukan untuk memulakan onboarding |
| Semakan sumber kempen | Medan sumber dan pengaruh cukup lengkap untuk keputusan bajet |
| Semakan pembaharuan | Kesihatan, tarikh pembaharuan, isyarat pengembangan, dan risiko adalah semasa |
Ini memberikan pengurus piawaian bimbingan. Berbanding menyebut "kemaskini CRM," mereka boleh menyebut "opportunity ini belum sedia untuk semakan kerana langkah seterusnya sudah usang dan tarikh tutup tidak disokong."
Bina buku panduan penerimaan khusus peranan
Peranan yang berbeza menerima kerana sebab yang berbeza.
Buku panduan wakil jualan
Untuk wakil jualan, penerimaan perlu mengurangkan soalan berulang dan memperbaiki sokongan deal.
CRM perlu membantu wakil jualan mengetahui akaun mana yang memerlukan perhatian, bersedia untuk semakan deal, mendapat bimbingan pengurus daripada konteks semasa, mengelakkan menjelaskan semula deal yang sama, dan mencetuskan kelulusan atau serah tugas tanpa mesej tambahan.
Jika CRM hanya mencipta kerja pelaporan, wakil jualan akan meminimumkan kemasukan. Jika ia memudahkan semakan deal, penerimaan menjadi rasional.
Buku panduan pengurus
Untuk pengurus, penerimaan perlu memperbaiki pemeriksaan dan bimbingan.
Pengurus memerlukan paparan yang menunjukkan rekod yang usang atau berisiko, definisi yang jelas untuk peringkat dan kategori ramalan, contoh kemasukan yang baik dan lemah, irama semakan mingguan, dan kuasa untuk menolak rekod yang tidak lengkap.
Pengurus adalah pendarab penerimaan. Seorang pengurus yang menjalankan kerja daripada hamparan boleh membatalkan sebulan latihan RevOps dalam satu mesyuarat.
Buku panduan pemasaran
Untuk pemasaran, penerimaan bergantung kepada sama ada data sumber dan funnel bertahan melalui serah tugas kepada jualan.
Pemasaran memerlukan peraturan sumber asal dan sumber terkini yang jelas, definisi pengaruh kempen, peraturan penukaran lead yang mengekalkan konteks sumber, maklum balas daripada jualan tentang kualiti, dan pelaporan pipeline yang menggunakan definisi yang dipersetujui.
Jika jualan boleh menulis semula sumber tanpa pengawal, pemasaran tidak akan mempercayai CRM. Jika pemasaran mengimport rekod tanpa kawalan kualiti, jualan tidak akan mempercayai CRM.
Buku panduan customer success
Untuk customer success, penerimaan bergantung kepada kualiti serah tugas dan sejarah akaun.
Customer success memerlukan konteks closed-won, risiko pelaksanaan, pihak berkepentingan, nota champion, butiran kontrak, minat produk, hasil yang dijanjikan, dan halangan yang diketahui.
Jika customer success perlu bertanya jualan maklumat yang sama sekali lagi, aliran kerja serah tugas telah gagal. Penerimaan bertambah baik apabila customer success menggunakan medan CRM serta-merta dan memberikan maklum balas apabila konteks serah tugas lemah.
Buku panduan finance
Untuk finance, penerimaan bergantung kepada definisi dan penyesuaian.
Finance memerlukan kategori ramalan dengan makna yang stabil, status pelanggan yang sepadan dengan realiti pengebilan, tarikh tutup dan jumlah yang boleh dipercayai, layanan yang jelas terhadap churn, pengembangan, dan pembaharuan, serta amaran data apabila definisi berubah.
Jika finance membina semula setiap laporan hasil di luar CRM, penerimaan telah gagal di lapisan eksekutif, walaupun pengguna masih mencatat aktiviti.
Kesan penerimaan palsu
Penerimaan palsu kelihatan baik dalam dashboard tetapi lemah dalam kerja sebenar.
Tanda amaran:
- Medan wajib lengkap tetapi penuh dengan "Tidak Diketahui" atau "Lain-lain"
- Pengguna log masuk kerap tetapi opportunity sudah usang
- Pengurus mengeksport laporan sebelum setiap mesyuarat
- Medan serah tugas diisi tetapi customer success tidak menggunakannya
- Kategori ramalan lengkap tetapi tiada bukti
- Medan sumber lengkap tetapi pemasaran mempertikaikannya
- Tugasan dicipta secara automatik tetapi diabaikan
Penerimaan palsu biasanya bermaksud RevOps mengukur aktiviti berbanding kualiti aliran kerja.
Penyelesaiannya bukan lebih banyak tekanan. Penyelesaiannya ialah menjejaki di mana data berhenti menjadi berguna.
Bina gelung maklum balas yang boleh dipercayai pengguna
Pengguna berhenti memberi maklum balas apabila tiada apa-apa berubah.
Gelung maklum balas yang berfungsi mempunyai empat bahagian:
- Tempat yang mudah untuk melaporkan geseran CRM.
- Seorang pemilik triage yang mengklasifikasikan isu.
- Keputusan yang jelas dilihat: baiki, tolak, tangguh, atau perlukan konteks lanjut.
- Nota keluaran (release note) apabila isu itu diperbaiki.
Ini memberikan RevOps maklum balas produk yang lebih baik, dan ia menunjukkan kepada pengguna bahawa penerimaan bukan tuntutan sehala. Sistem menjadi lebih baik kerana orang melaporkan apa yang menghalang mereka.
Gelung maklum balas juga perlu melindungi RevOps daripada aduan yang kabur. "CRM ini teruk" tidak boleh ditindaklanjuti. "Medan risiko pelaksanaan diwajibkan sebelum saya mengetahui jawapannya" boleh ditindaklanjuti.
Bina irama penerimaan
Penerimaan memerlukan irama, bukan pelancaran sekali sahaja.
Mingguan:
- Semak kebersihan pipeline aktif
- Semak medan yang diperlukan untuk ramalan
- Periksa kesediaan serah tugas
- Perhatikan trend rekod pendua atau usang
Bulanan:
- Semak metrik penerimaan mengikut pasukan
- Kumpulkan maklum balas pengurus
- Kenal pasti titik geseran
- Sarakan medan atau paparan yang tidak digunakan
- Semak corak kualiti data dalam kebersihan data CRM
Suku tahunan:
- Audit aliran kerja
- Segarkan semula contoh latihan
- Semak perubahan sistem
- Kemaskini definisi
- Sahkan semula jangkaan pengurus
Irama ini menjadikan penerimaan sebahagian daripada irama operasi hasil.
Gunakan latihan secara berbeza
Kebanyakan latihan CRM menerangkan di mana untuk klik.
Latihan yang lebih baik menerangkan kenapa aliran kerja itu wujud.
Gunakan contoh sebenar:
- Kemasukan opportunity yang baik
- Kemasukan opportunity yang lemah
- Serah tugas closed-won yang boleh digunakan CS
- Kategori ramalan dengan bukti
- Rekod pendua yang merosakkan pemilikan
- Medan yang diisi terlalu awal dengan data palsu
- Semakan pengurus yang menggunakan data CRM dengan betul
Latihan perlu dikaitkan dengan irama pengurus. Jika satu medan diajar tetapi tidak pernah diperiksa, pengguna akan melupakannya.
Latih pengurus sebelum pengguna
Untuk perubahan penerimaan CRM yang besar, latih pengurus terlebih dahulu.
Pengurus perlu tahu:
- Medan mana yang penting
- Kenapa medan itu penting
- Rupa data yang baik
- Rupa data yang lemah
- Cara membimbing data yang hilang atau palsu
- Laporan mana yang perlu digunakan
- Jalan pintas mana yang perlu dihentikan penerimaannya
- Ke mana untuk menghantar maklum balas
Jika pengurus tidak bersedia, latihan pengguna akan pudar dengan cepat.
Gunakan perubahan CRM dengan berhati-hati
Penerimaan boleh bertambah baik selepas perubahan CRM, tetapi hanya jika perubahan itu diuruskan dengan baik.
Medan yang mengejutkan, peraturan pengesahan yang tiba-tiba, perubahan laporan yang tidak dijelaskan, dan automasi yang tidak diumumkan boleh merosakkan kepercayaan. Setiap perubahan penerimaan yang bermakna perlu mempunyai pelan pelancaran, terutamanya jika ia menjejaskan jurujual, pengurus, customer success, atau finance.
Kerja penerimaan perlu berkait dengan CRM change management apabila aliran kerja, medan wajib, dashboard, atau automasi sedang berubah.
Penerimaan mengikut peranan
Peranan yang berbeza memerlukan nilai yang berbeza.
| Peranan | Apa yang menjadikan CRM berbaloi digunakan | Risiko penerimaan |
|---|---|---|
| Wakil jualan | Keutamaan yang jelas, kurang soalan berulang, semakan deal yang lebih mudah | Terlalu banyak pentadbiran, tidak cukup nilai |
| Pengurus | Pipeline semasa, keterlihatan risiko, bukti bimbingan | Hamparan berasingan kekal lebih mudah |
| Pemasaran | Kualiti sumber, maklum balas penukaran, pengaruh kempen | Jualan tidak mengekalkan konteks sumber |
| Customer success | Serah tugas bersih, risiko pembaharuan, sejarah akaun | Serah tugas jualan tidak lengkap |
| Finance | Kepercayaan ramalan, status pelanggan, andaian hasil | Medan CRM tidak diselaraskan |
| Eksekutif | Metrik yang konsisten dan kurang hamparan bayangan | Pemimpin meminta laporan sampingan tersuai |
Inilah sebabnya latihan generik jarang berkesan. Penerimaan perlu berkait dengan tugas yang cuba dilakukan oleh setiap peranan.
Penerimaan dan insentif
Penerimaan juga bergantung kepada insentif.
Jika wakil jualan diukur hanya berdasarkan hasil yang ditutup, mereka mungkin menganggap kebersihan CRM sebagai kerja pentadbiran. Jika pengurus diukur hanya berdasarkan penyerahan ramalan, mereka mungkin membiarkan butiran opportunity yang lemah selagi angka itu diserahkan. Jika customer success diukur berdasarkan pembaharuan tetapi tiada pengaruh terhadap kualiti serah tugas closed-won, penerimaan serah tugas akan kekal lemah.
RevOps tidak sepatutnya mereka bentuk pampasan bersendirian, tetapi ia perlu menunjukkan di mana insentif melemahkan kualiti data. Aliran kerja yang disebut penting oleh kepimpinan tetapi tidak pernah diperiksa tidak akan menjadi tabiat.
Set semula penerimaan yang praktikal
Gunakan ini apabila kepercayaan CRM sudah rendah.
- Kenal pasti aliran kerja yang paling diperlukan oleh kepimpinan.
- Senaraikan medan yang menyokong aliran kerja tersebut.
- Buang atau sembunyikan medan bernilai rendah jika boleh.
- Baiki isu rekod pendua dan usang dalam aliran kerja aktif.
- Latih pengurus tentang apa yang perlu diperiksa.
- Lancarkan semula aliran kerja dengan contoh.
- Semak penerimaan setiap minggu selama 30 hari.
- Terbitkan pembaikan supaya pengguna melihat kemajuan.
Intinya ialah menyempitkan sistem sekitar kerja yang penting. Penerimaan bertambah baik apabila pengguna melihat bahawa RevOps mengurangkan gangguan, bukan hanya menuntut lebih banyak data.
30 hari pertama selepas set semula
Selepas set semula penerimaan, kekalkan skop sempit selama 30 hari.
Pilih satu aliran kerja, seperti kemasukan opportunity sebelum semakan ramalan atau kelengkapan serah tugas closed-won. Ukur medan utama, bimbing pengurus, kumpulkan maklum balas, dan terbitkan pembaikan. Kemenangan sempit membina lebih banyak kepercayaan berbanding pelancaran semula yang luas yang mengubah terlalu banyak tingkah laku sekali gus.
Semasa bulan pertama, RevOps perlu perhatikan:
- Kelengkapan medan
- Nilai sementara
- Kualiti pemeriksaan pengurus
- Kadar rekod usang
- Soalan sokongan
- Penggunaan jalan pintas
- Tema maklum balas pengguna
Jangan berkembang sehingga aliran kerja pertama berfungsi.
Hari 31 hingga 60
Bulan kedua adalah masa untuk RevOps mengubah set semula menjadi tabiat.
Tindakan:
- Pindahkan aliran kerja ke dalam mesyuarat tetap
- Kemaskini contoh latihan daripada rekod sebenar
- Buang medan yang terbukti tidak berguna
- Tala peraturan pengesahan yang mencipta geseran
- Tambah kad skor pengurus
- Terbitkan hasil sebelum-dan-selepas
Pengguna perlu melihat bahawa maklum balas membawa kepada pembaikan. Jika tidak, kerja penerimaan terasa seperti dorongan pematuhan sehala.
Hari 61 hingga 90
Bulan ketiga adalah masa model penerimaan berkembang.
Pilih aliran kerja seterusnya hanya selepas yang pertama menunjukkan penambahbaikan yang boleh diukur. Sebagai contoh:
- Selepas kualiti kemasukan pipeline bertambah baik, beralih kepada bukti kategori ramalan.
- Selepas kelengkapan serah tugas bertambah baik, beralih kepada semakan kesihatan pelanggan.
- Selepas kualiti sumber bertambah baik, beralih kepada pelaporan atribusi.
Ini mencipta corak penerimaan yang bertambah. Satu aliran kerja yang lebih bersih memberikan pengurus mesyuarat yang lebih baik. Mesyuarat yang lebih baik memberikan pengguna sebab untuk mengekalkan rekod semasa. Rekod semasa memudahkan aliran kerja seterusnya diperbaiki.
Contoh: penerimaan ramalan
Penerimaan ramalan bertambah baik apabila pengurus dan wakil jualan melihat bahawa CRM mengubah perbualan.
Jika seorang wakil jualan mengemaskini tarikh tutup, langkah seterusnya, dan kategori ramalan tetapi panggilan ramalan masih berlaku daripada hamparan, wakil jualan itu belajar bahawa kemasukan CRM adalah pilihan sahaja. Jika panggilan ramalan menggunakan pakej CRM dan pengurus bertanya tentang bukti yang hilang terus daripada rekod, wakil jualan belajar bahawa data CRM itu penting.
Mekanisme penerimaan bukan peringatan. Ia adalah reka bentuk mesyuarat.
Penerimaan ramalan perlu berkait dengan pipeline inspection cadence, kerana semakan pipeline adalah tempat di mana banyak masalah data ramalan sepatutnya dikesan sebelum panggilan.
Contoh: penerimaan serah tugas closed-won
Medan serah tugas closed-won sering gagal kerana jualan menganggapnya sebagai pentadbiran selepas jualan. Penerimaan bertambah baik apabila customer success menggunakan medan itu serta-merta.
Jika CS bertanya soalan yang sama sekali lagi dalam Slack, jualan belajar bahawa medan serah tugas itu tidak penting. Jika CS memulakan onboarding daripada serah tugas CRM dan menandakan konteks yang hilang kembali kepada pengurus, serah tugas itu menjadi sebahagian daripada irama operasi.
Mekanisme penerimaan ialah penggunaan hiliran.
Contoh: penerimaan sumber
Data sumber gagal apabila ia dianggap sebagai medan pelaporan peribadi pemasaran.
Jika jualan menukar sumber secara sambil lewa, pemasaran kehilangan kepercayaan atribusi. Jika pemasaran mengimport lead tanpa peraturan sumber yang jelas, jualan kehilangan konteks. Jika eksekutif meminta pelaporan sumber tetapi tiada siapa memiliki definisi, medan itu menjadi bersifat politik.
Penerimaan bertambah baik apabila medan sumber ditakrifkan, dikekalkan, dan digunakan dalam semakan kempen dan pipeline. Orang mengekalkan medan yang muncul dalam keputusan.
Apa yang RevOps tidak sepatutnya lakukan
RevOps tidak sepatutnya bertindak balas terhadap penerimaan yang lemah dengan menambah lebih banyak medan wajib, lebih banyak amaran, atau lebih banyak dashboard tanpa mendiagnosis aliran kerja.
Tindak balas buruk yang biasa:
- Mewajibkan setiap medan lebih awal
- Menambah peringatan pop timbul
- Membina dashboard pematuhan yang tiada siapa gunakan
- Menyalahkan wakil jualan tanpa pemeriksaan pengurus
- Melatih pengguna semula tanpa mengubah proses
- Mengabaikan hamparan yang masih digunakan pemimpin
Tindak balas yang lebih baik ialah membuang geseran, menjelaskan nilai, dan menjadikan tingkah laku yang betul jelas dilihat dalam mesyuarat yang sudah penting.
Kesilapan penerimaan CRM biasa
Menganggap penerimaan sebagai pematuhan pengguna. Sistem itu sendiri mungkin masalahnya.
Hanya mengukur log masuk. Aktiviti tidak membuktikan data yang berguna.
Menambah lebih banyak medan wajib. Lebih banyak medan wajib boleh mengurangkan kepercayaan.
Melangkau pemerkasaan pengurus. Pengguna mengikut apa yang diperiksa pengurus.
Mengabaikan jalan pintas. Hamparan dan permintaan Slack mendedahkan aliran kerja yang rosak.
Tiada gelung maklum balas. Pengguna berhenti melaporkan geseran apabila tiada apa-apa berubah.
Melancarkan terlalu meluas. Dorongan penerimaan yang luas selalunya mengubah terlalu banyak tingkah laku sekali gus.
Latihan tanpa reka bentuk mesyuarat. Pengguna melupakan aliran kerja yang tidak pernah diperiksa pengurus.
Rupa penerimaan yang baik
Penerimaan yang baik jelas dilihat dalam mesyuarat operasi.
Semakan pipeline bermula daripada rekod CRM. Panggilan ramalan menggunakan data yang sama yang dilihat finance. Customer success mempercayai medan serah tugas. Pengurus membimbing daripada nota opportunity semasa. Wakil jualan berhenti mengekalkan hamparan sampingan kerana CRM membantu mereka menggerakkan kerja ke hadapan.
Sistem menjadi permukaan kerja untuk hasil, bukan tempat orang mengemaskini selepas kerja sebenar berlaku di tempat lain.
Isyarat terbaik bukanlah setiap pengguna menyukai CRM. Isyarat terbaik ialah CRM cukup dipercayai untuk menjalankan kerja.
Model kematangan penerimaan
| Peringkat | Tingkah laku | Langkah RevOps |
|---|---|---|
| Pematuhan | Pengguna mengemaskini medan kerana ia diwajibkan | Buang geseran buruk dan kesempurnaan palsu |
| Pemeriksaan | Pengurus memeriksa medan kritikal dalam mesyuarat irama | Latih pengurus dan reka bentuk semula mesyuarat |
| Pertukaran nilai | Pengguna menerima nilai aliran kerja daripada data yang mereka masukkan | Perbaiki laporan, penghalaan, serah tugas, dan bimbingan |
| Sistem operasi | CRM menjadi permukaan kerja lalai untuk keputusan hasil | Kekalkan kepercayaan melalui governance dan maklum balas |
Kebanyakan pasukan tersekat antara pematuhan dan pemeriksaan. Mereka menambah medan wajib tetapi tidak mengubah irama. RevOps perlu memindahkan penerimaan ke dalam tingkah laku pengurus dan aliran keputusan.
Pakej diagnosis penerimaan
Masalah penerimaan CRM memerlukan diagnosis sebelum penguatkuasaan.
Rekodkan:
- Aliran kerja di mana penerimaan gagal.
- Peranan pengguna yang terjejas.
- Medan atau tindakan yang dilangkau.
- Sebab pengguna mengelakkannya.
- Tingkah laku pemeriksaan pengurus.
- Geseran automasi atau UX.
- Kesan pelaporan.
- Pemilik pembaikan.
Ini menghalang jawapan lalai "latih pengguna semula." Kadangkala masalahnya ialah latihan. Selalunya ia adalah reka bentuk medan, geseran aliran kerja, jangkaan pengurus yang tidak jelas, atau proses CRM yang tidak sepadan dengan kerja sebenar.
Soalan Lazim
Siapa yang memiliki penerimaan CRM?
RevOps memiliki model penerimaan dan reka bentuk sistem. Pengurus memiliki penguatkuasaan. Pemimpin fungsian memiliki jangkaan. Pengguna memiliki rekod yang mereka sentuh. Penerimaan gagal apabila RevOps dijangka membaiki tingkah laku tanpa sokongan pengurus.
Apa metrik penerimaan yang terbaik?
Metrik terbaik adalah khusus aliran kerja. Untuk pipeline, gunakan langkah seterusnya semasa dan bukti peringkat. Untuk ramalan, gunakan kualiti kategori dan kadar tarikh usang. Untuk serah tugas, gunakan kelengkapan dan penggunaan hiliran.
Kenapa program penerimaan CRM gagal?
Ia gagal apabila fokus kepada peringatan, latihan, atau dashboard pematuhan tanpa mengubah aliran kerja. Penerimaan bertambah baik apabila CRM menjadi tempat pengurus memeriksa kerja dan pengguna menerima nilai.
Berapa lama masa yang diambil untuk set semula penerimaan CRM?
Set semula yang sempit boleh menunjukkan kemajuan dalam 30 hari. Penerimaan yang lebih luas biasanya mengambil masa 90 hari atau lebih kerana tingkah laku pengurus, reka bentuk medan, kepercayaan pelaporan, dan tabiat pengguna semuanya perlu berubah.
Ketahui lebih lanjut

Senior Operations & Growth Strategist
On this page
- Kenapa penerimaan CRM gagal
- Penerimaan bergantung kepada pertukaran nilai
- Model penerimaan RevOps
- Reka bentuk medan berdasarkan keputusan
- Tetapkan masa medan wajib mengikut aliran kerja
- Libatkan pengurus dalam gelung
- Jadikan mesyuarat menguatkuasakan model operasi
- Kurangkan geseran sebelum menambah peringatan
- Diagnosis jalan pintas
- Ukur penerimaan berdasarkan tingkah laku, bukan log masuk
- Bina kad skor penerimaan
- Tambah kawalan operasi
- Tentukan kriteria penerimaan aliran kerja
- Bina buku panduan penerimaan khusus peranan
- Buku panduan wakil jualan
- Buku panduan pengurus
- Buku panduan pemasaran
- Buku panduan customer success
- Buku panduan finance
- Kesan penerimaan palsu
- Bina gelung maklum balas yang boleh dipercayai pengguna
- Bina irama penerimaan
- Gunakan latihan secara berbeza
- Latih pengurus sebelum pengguna
- Gunakan perubahan CRM dengan berhati-hati
- Penerimaan mengikut peranan
- Penerimaan dan insentif
- Set semula penerimaan yang praktikal
- 30 hari pertama selepas set semula
- Hari 31 hingga 60
- Hari 61 hingga 90
- Contoh: penerimaan ramalan
- Contoh: penerimaan serah tugas closed-won
- Contoh: penerimaan sumber
- Apa yang RevOps tidak sepatutnya lakukan
- Kesilapan penerimaan CRM biasa
- Rupa penerimaan yang baik
- Model kematangan penerimaan
- Pakej diagnosis penerimaan
- Soalan Lazim
- Siapa yang memiliki penerimaan CRM?
- Apa metrik penerimaan yang terbaik?
- Kenapa program penerimaan CRM gagal?
- Berapa lama masa yang diambil untuk set semula penerimaan CRM?
- Ketahui lebih lanjut