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:

  1. Tempat yang mudah untuk melaporkan geseran CRM.
  2. Seorang pemilik triage yang mengklasifikasikan isu.
  3. Keputusan yang jelas dilihat: baiki, tolak, tangguh, atau perlukan konteks lanjut.
  4. 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.

  1. Kenal pasti aliran kerja yang paling diperlukan oleh kepimpinan.
  2. Senaraikan medan yang menyokong aliran kerja tersebut.
  3. Buang atau sembunyikan medan bernilai rendah jika boleh.
  4. Baiki isu rekod pendua dan usang dalam aliran kerja aktif.
  5. Latih pengurus tentang apa yang perlu diperiksa.
  6. Lancarkan semula aliran kerja dengan contoh.
  7. Semak penerimaan setiap minggu selama 30 hari.
  8. 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

About the author

Tara Minh

Tara Minh

Senior Operations & Growth Strategist

Tara Minh is Senior Operations & Growth Strategist at Rework, helping B2B SaaS leaders scale without breaking their teams. With 8+ years in revenue operations and process optimization, Tara turns messy workflows into systems people actually follow. Readers get practical frameworks they can use to cut waste, align teams, and grow on purpose.