Tadbir Urus Medan CRM: Cara RevOps Mengekalkan Data Hasil Boleh Digunakan

Setiap medan CRM adalah satu janji.

Ia menjanjikan bahawa seseorang tahu maksud medan itu, bila ia perlu diisi, siapa memilikinya, dan keputusan mana yang bergantung kepadanya. Kebanyakan syarikat memungkiri janji itu. Mereka menambah medan dengan pantas, lupa sebabnya, dan kemudian tertanya-tanya mengapa laporan tidak boleh dipercayai.

Tadbir urus medan CRM ialah cara RevOps melindungi CRM daripada menjadi tempat perkuburan permintaan lama, nilai yang tidak digunakan, definisi yang tidak jelas, dan medan wajib yang hanya diisi pengguna untuk terus maju.

Tadbir urus medan bukan tentang menolak setiap permintaan. Ia adalah tentang memastikan setiap medan yang memasuki CRM layak mendapat tempatnya dan terus layak dari semasa ke semasa.

Penyelidikan penjajaran teknologi RevOps oleh Forrester relevan kerana medan CRM membentuk aliran kerja, dashboard, automasi, integrasi, dan pelaporan eksekutif. Model tanggungjawab RevOps oleh Forrester turut menegaskan mengapa tadbir urus medan perlu merentasi pemasaran, jualan, kejayaan pelanggan, kewangan, dan sistem.

Fakta operasi utama

• Setiap medan CRM perlu mempunyai sebab keputusan, aliran kerja, laporan, atau serah tugas.
• Medan wajib perlu muncul apabila pengguna dapat mengetahui jawapannya.
• Pemilikan medan berbeza daripada penyiapan medan. Pemilik mengekalkan maksud dan kualiti.
• Penamatan medan adalah sebahagian daripada tadbir urus, bukan pembersihan.
• Tadbir urus medan yang lemah menjadikan dashboard, automasi, dan aliran kerja AI kurang boleh dipercayai.

Mengapa medan CRM merosot

Medan CRM merosot kerana setiap permintaan kelihatan munasabah secara berasingan.

Jualan mahukan medan untuk risiko deal. Pemasaran mahukan medan untuk sumber kempen. Kewangan mahukan medan untuk layanan pengebilan. Kejayaan pelanggan mahukan konteks onboarding. Seorang pengurus mahukan medan untuk inisiatif khas. Seorang eksekutif mahukan potongan dashboard.

Enam bulan kemudian, pengguna melihat susun atur yang sesak, laporan bercanggah, dan tiada siapa ingat medan mana yang masih penting.

Tadbir urus medan wujud untuk menjawab tiga soalan sebelum medan ditambah:

• Keputusan atau aliran kerja apa yang disokong oleh medan ini?
• Siapa memiliki definisi dan kualiti?
• Bila medan itu perlu diwajibkan, jika ada?

Jika soalan tersebut tidak dijawab, medan itu tidak sepatutnya ditambah lagi.

Kos tadbir urus medan yang lemah

Tadbir urus medan yang lemah mencipta kos di tempat yang mudah terlepas pandang.

Kos yang tersembunyi ialah kepercayaan. Apabila pengguna mengetahui banyak medan tidak penting, mereka meragui medan yang benar-benar penting.

Apa yang diliputi oleh tadbir urus medan

Tadbir urus medan lebih daripada kelulusan.

Ia merangkumi:

• Pengambilan permintaan medan
• Semakan sebab perniagaan
• Pemilihan objek dan jenis medan
• Definisi dan nilai yang dibenarkan
• Pemilikan
• Masa medan wajib
• Penempatan susun atur halaman
• Kesan pelaporan dan automasi
• Kesan integrasi
• Kemas kini kamus data
• Pemantauan selepas pelancaran
• Dasar penamatan

Ini berkait secara langsung dengan kamus data hasil, pengurusan perubahan CRM, dan kebersihan data CRM.

Gunakan pengambilan permintaan medan

Jangan cipta medan daripada permintaan santai.

Gunakan pengambilan ringkas:

• Apakah nama medan itu?
• Objek mana yang memerlukannya?
• Masalah apa yang diselesaikannya?
• Siapa menggunakan data itu?
• Keputusan mana yang bergantung kepadanya?
• Bolehkah data itu ditangkap daripada medan sedia ada?
• Perlukah ia berbentuk picklist, tarikh, lookup, checkbox, nombor, formula, atau teks?
• Bila pengguna dapat mengetahui jawapannya?
• Perlukah ia diwajibkan?
• Siapa memiliki kualiti?
• Laporan atau aliran kerja mana yang akan menggunakannya?
• Apa berlaku jika medan itu kosong?
• Apa berlaku jika pengguna memasukkan nilai buruk?

Banyak permintaan medan akan hilang apabila pemohon perlu mentakrifkan keputusan tersebut. Itu sihat. Ia bermaksud CRM tidak digunakan sebagai buku nota untuk idea yang belum selesai.

Gunakan ujian keputusan medan

Sebelum meluluskan medan, RevOps perlu menggunakan ujian ringkas.

Jika permintaan itu tidak dapat lulus ujian ini, jawapannya bukan sentiasa tidak. Kadangkala jawapannya ialah "belum lagi," "gunakan medan sedia ada," "mulakan dengan laporan," atau "takrifkan aliran kerja dahulu."

Pilih objek yang betul

Tadbir urus medan bermula sebelum jenis medan. Pertama, tentukan di mana medan itu tergolong.

Konsep yang sama boleh tergolong pada objek berbeza bergantung kepada cara perniagaan menggunakannya.

Meletakkan data pada objek yang salah mencipta masalah pelaporan kemudian. Contoh: risiko pelaksanaan mungkin terasa seperti medan peluang, tetapi jika kejayaan pelanggan menjejakinya selepas penutupan, pasukan juga mungkin memerlukannya pada objek serah tugas atau pelanggan.

Pilih jenis medan dengan berhati-hati

Jenis medan menjejaskan pelaporan, automasi, pengalaman pengguna, dan kualiti data.

Medan teks bebas menarik kerana ia fleksibel. Ia juga sukar dilaporkan. Gunakannya apabila nuansa penting, bukan apabila perniagaan memerlukan segmentasi yang konsisten.

Tadbir urus picklist dengan ketat

Picklist kelihatan mudah, tetapi ia sering mencipta hutang pelaporan jangka panjang.

Picklist yang baik memerlukan:

• Label nilai yang jelas
• Definisi untuk setiap nilai
• Pemilik
• Laluan "Lain-lain" yang dibenarkan
• Proses penamatan untuk nilai lama
• Pemetaan daripada nilai import
• Penggunaan pelaporan
• Pengendalian terjemahan atau serantau jika diperlukan

Picklist yang lemah mencipta pilihan palsu. Pengguna memilih nilai yang paling hampir, atau terlalu kerap menggunakan "Lain-lain," dan laporan menjadi kurang berguna.

Contoh: sebab closed-lost tidak sepatutnya mempunyai 35 nilai. Ia perlu mempunyai nilai yang cukup untuk menyokong analisis kehilangan tanpa memaksa wakil jualan mentafsir perbezaan kecil yang tidak pernah diperiksa pengurus.

Sesuaikan masa medan wajib dengan aliran kerja

Medan wajib adalah salah satu cara terpantas merosakkan penerimaan.

Medan patut diwajibkan hanya apabila:

• Pengguna secara munasabah dapat mengetahui jawapannya
• Data itu menyokong keputusan sebenar
• Nilai itu diperiksa
• Medan itu mempunyai nilai yang dibenarkan jelas
• Pengguna tahu rupa data yang baik
• Pengecualian mempunyai laluan

Contoh: status undang-undang mungkin diwajibkan sebelum peluang peringkat akhir memasuki commit, tetapi bukan semasa discovery. Risiko pelaksanaan mungkin diwajibkan sebelum closed-won, tetapi bukan apabila peluang itu mula-mula dicipta.

Ini adalah teras kepada medan wajib berbanding medan berguna. Diwajibkan pada masa yang salah mencipta data palsu. Diwajibkan pada masa yang betul mencipta proses yang lebih baik.

Tetapkan pemilikan medan

Setiap medan penting memerlukan pemilik.

Pemilik bertanggungjawab terhadap:

• Definisi
• Nilai yang dibenarkan
• Jangkaan kualiti
• Penggunaan pelaporan
• Kelulusan perubahan
• Keputusan penamatan
• Pengendalian pengecualian

Pemilikan tidak bermaksud satu orang mengisi medan itu. Ia bermaksud satu peranan bertanggungjawab sama ada medan itu kekal berguna.

Contoh pemilikan:

Tanpa pemilik, medan menjadi kekusutan bersama.

Dokumenkan definisi sebelum pelancaran

Definisi medan perlu ditulis sebelum medan itu dilancarkan.

Sekurang-kurangnya, dokumenkan:

• Label medan
• Nama API jika berkaitan
• Objek
• Definisi
• Pemilik
• Nilai yang dibenarkan
• Masa wajib
• Penggunaan laporan atau aliran kerja
• Sistem sumber
• Peraturan kemas kini
• Tarikh semakan penamatan

Ini tidak perlu menjadi proses yang berat. Tetapi jika medan itu menjejaskan pelaporan atau automasi bersama, definisi mesti jelas sebelum pengguna melihatnya.

Semak kesan pelaporan dan automasi

Sebelum menambah atau mengubah medan, semak di mana ia akan digunakan.

Adakah ia menyokong:

• Dashboard
• Pakej ramalan
• Peraturan penghalaan
• Aliran kerja SLA
• Serah tugas pelanggan
• Pelaporan kepada lembaga
• Enrichment
• Integrasi
• Pemarkahan AI
• Penyesuaian kewangan

Jika medan itu menyokong automasi, jadilah lebih tegas. Nilai medan yang buruk boleh mencipta tindakan aliran kerja yang buruk.

Jika medan itu menyokong pelaporan eksekutif, dokumenkan definisi sebelum pelancaran. Pemimpin tidak sepatutnya berbalah tentang maksud medan dalam mesyuarat.

Semak kesan integrasi

Medan jarang kekal dalam satu sistem sahaja.

Medan CRM mungkin disegerakkan kepada automasi pemasaran, sales engagement, kejayaan pelanggan, pengebilan, data warehouse, atau reverse ETL. Ia mungkin baca sahaja dalam satu sistem dan boleh disunting dalam sistem lain. Ia mungkin dicipta dalam satu alat dan dilaporkan daripada alat lain.

Sebelum pelancaran, dokumenkan:

• Sistem mana yang membaca medan itu
• Sistem mana yang menulis kepadanya
• Sistem mana yang menang jika nilai bercanggah
• Sama ada nilai sejarah memerlukan backfill
• Sama ada nilai kosong dibenarkan
• Siapa memiliki ralat penyegerakan

Kesan integrasi adalah tempat di mana banyak perubahan medan "kecil" menjadi perubahan berisiko tinggi.

Cipta kitaran hayat medan

Medan memerlukan kitaran hayat.

1. Diminta
2. Disemak
3. Diluluskan
4. Dibina
5. Didokumenkan
6. Dilancarkan
7. Dipantau
8. Disemak semula atau ditamatkan

Kebanyakan pasukan melakukan langkah 1 hingga 4 dan melangkau selebihnya. Itulah sebabnya CRM merosot.

Selepas pelancaran, RevOps perlu memantau:

• Kadar penyiapan
• Nilai placeholder
• Taburan nilai
• Penggunaan laporan
• Pemeriksaan pengurus
• Soalan pengguna
• Kesan aliran kerja
• Ralat integrasi

Jika medan itu tidak digunakan, tamatkan atau ubahnya.

Pantau kualiti medan

Kualiti medan perlu disemak selepas pelancaran.

Semakan yang berguna:

• Adakah medan itu diisi?
• Adakah pengguna terlalu kerap memasukkan "Tidak diketahui," "Lain-lain," atau placeholder?
• Adakah nilai diagihkan secara realistik?
• Adakah medan itu muncul dalam laporan yang benar-benar digunakan orang?
• Adakah medan itu mencetuskan automasi dengan betul?
• Adakah pengurus memeriksanya?
• Adakah pengguna bertanya soalan yang sama berulang kali?
• Adakah medan itu berganda di tempat lain?

Di sinilah tadbir urus medan menyokong penerimaan CRM. Pengguna lebih mempercayai medan apabila medan yang lemah dibetulkan atau dibuang.

Tamatkan medan secara sengaja

Penamatan medan adalah tadbir urus, bukan pembersihan.

Sebelum menamatkan medan:

• Semak laporan
• Semak automasi
• Semak integrasi
• Semak keperluan analisis sejarah
• Semak templat import
• Beritahu pemilik
• Arkibkan definisi jika perlu
• Putuskan sama ada untuk menyembunyikan sebelum penghapusan

Sesetengah medan patut disembunyikan sebelum dihapuskan. Yang lain patut kekal untuk pelaporan sejarah tetapi ditinggalkan daripada susun atur aktif. RevOps perlu membezakan "tidak digunakan lagi" daripada "diperlukan untuk analisis sejarah."

Uruskan backfill dengan berhati-hati

Apabila medan baharu ditambah, tentukan sama ada rekod lama memerlukan backfill.

Sesetengah medan hanya penting untuk masa hadapan. Yang lain menjejaskan pelaporan sejarah atau pipeline aktif. Jika backfill diperlukan, tentukan siapa akan melakukannya, rekod mana yang dalam skop, dan sama ada nilai tidak diketahui dibenarkan.

Jangan paksa pengguna membersihkan bertahun-tahun rekod lama melainkan perniagaan memerlukan sejarah itu.

Backfill tanpa skop menjadi kerja tersembunyi. Tadbir urus medan perlu menjadikan kerja itu kelihatan sebelum pelancaran.

Tadbir urus susun atur halaman

Tadbir urus medan turut merangkumi di mana medan muncul.

Medan penting perlu muncul berhampiran aliran kerja yang menggunakannya. Medan bernilai rendah tidak sepatutnya menyesakkan halaman. Medan wajib perlu dikumpulkan di sekitar peringkat atau serah tugas di mana ia penting. Jika setiap medan muncul di mana-mana, pengguna berhenti melihat yang penting.

Susun atur halaman adalah reka bentuk penerimaan. Susun atur yang kemas memberitahu pengguna apa yang penting. Susun atur yang sesak memberitahu pengguna bahawa sistem itu tiada keutamaan.

Gunakan bajet geseran medan

Setiap pasukan mempunyai toleransi terhad terhadap geseran CRM.

Setiap medan wajib membelanjakan sebahagian daripada bajet itu. Setiap nilai tidak jelas membelanjakan lebih banyak. Setiap medan yang tidak digunakan sesiapa mengajar pengguna untuk meragui medan seterusnya.

Tadbir urus medan melindungi bajet itu dengan memastikan hanya medan berguna kekal kelihatan dan hanya medan yang perlu menjadi wajib.

Ini tidak bermaksud CRM patut mengelak permintaan yang sukar. Sesetengah medan mesti diwajibkan. Tetapi perniagaan patut membelanjakan geseran hanya di tempat data itu mengubah keputusan.

Cipta laluan tadbir urus

Pasukan kecil tidak memerlukan jawatankuasa formal untuk setiap medan.

Gunakan tiga peringkat:

Ini mengekalkan proses tetap ringan sambil melindungi medan berimpak tinggi.

Untuk medan berimpak tinggi, sertakan pemilik fungsi, RevOps, pemilik sistem, dan mana-mana pasukan hiliran yang bergantung kepada data itu. Kewangan, kejayaan pelanggan, pemasaran, atau kepimpinan jualan hanya menyertai apabila medan itu menjejaskan aliran kerja atau pelaporan mereka.

Bina peta kebergantungan medan

Medan berimpak tinggi perlu mempunyai peta kebergantungan.

Peta kebergantungan menunjukkan apa yang rosak apabila medan itu berubah.

Peta ini amat berguna sebelum mengubah nilai picklist, mewajibkan medan, menamatkan medan, atau menggunakan medan dalam automasi.

Tanpa peta kebergantungan, RevOps mungkin membaiki satu aliran kerja sambil secara senyap merosakkan tiga yang lain.

Susun peringkat medan mengikut risiko operasi

Tidak semua medan layak mendapat berat tadbir urus yang sama.

Cipta peringkat.

Peringkat ini menghalang dua hasil buruk.

Pertama, ia menghalang RevOps daripada mentadbir urus medan kecil secara berlebihan. Kedua, ia menghalang medan berisiko tinggi daripada dianggap seperti permintaan pentadbiran yang tidak berbahaya.

Cipta senarai semak pelancaran medan

Sebelum medan berisiko sederhana atau tinggi dilancarkan, gunakan senarai semak pelancaran.

Senarai semak ini tidak memerlukan mesyuarat yang panjang. Ia memerlukan jawapan sebenar untuk setiap item.

Jalankan irama tadbir urus medan

Tadbir urus medan perlu mempunyai rentak.

Mingguan atau dwi-mingguan:

• Semak permintaan medan baharu
• Luluskan perubahan berisiko rendah
• Tetapkan pemilik untuk permintaan berisiko sederhana dan tinggi
• Semak pelancaran medan yang akan datang
• Semak isu kualiti medan yang mendesak

Bulanan:

• Semak geseran medan wajib
• Periksa nilai placeholder
• Semak medan yang berkait dengan irama operasi semasa
• Semak nilai picklist dengan penggunaan "Lain-lain" yang tinggi
• Sahkan pemilik untuk medan bersama baharu

Suku tahunan:

• Tamatkan atau sembunyikan medan yang tidak digunakan
• Semak definisi Tier 1 dan Tier 2
• Kemas kini dokumentasi medan
• Audit kebergantungan pelaporan dan automasi
• Semak medan yang menjejaskan metrik eksekutif

Irama ini menghalang CRM daripada berubah secara senyap setiap hari. Ia juga memberikan pihak berkepentingan laluan yang boleh diramal untuk permintaan, yang mengurangkan penciptaan medan melalui saluran belakang.

Gunakan medan sementara dengan berhati-hati

Medan sementara kadangkala sah.

Sesebuah pasukan mungkin memerlukan medan untuk pilot, migrasi, kempen sekali sahaja, pembersihan data, atau inisiatif jangka pendek. Kesilapannya ialah membiarkan medan sementara menjadi kekal akibat kealpaan.

Medan sementara perlu mempunyai:

• Pemilik
• Tujuan
• Tarikh mula
• Tarikh tamat
• Peraturan keterlihatan
• Tarikh penamatan
• Skop pelaporan

Jika medan sementara masih wujud selepas tarikh tamat, RevOps perlu memutuskan sama ada untuk menamatkannya, menaikkannya kepada status tertadbir urus, atau menyembunyikannya daripada susun atur aktif.

Medan sementara tanpa tempoh luput adalah salah satu cara terpantas CRM menjadi berselerak.

Contoh: menambah medan pesaing

Jualan meminta medan pesaing kerana pengurus mahukan wawasan persaingan yang lebih baik.

Tanpa tadbir urus, RevOps menambah medan teks bebas. Enam bulan kemudian, CRM mempunyai "Salesforce," "SFDC," "sales force," "Hubspot," "HS," dan nilai kosong. Pelaporan lemah, dan pengurus berhenti menggunakan medan itu.

Dengan tadbir urus, RevOps bertanya keputusan mana yang disokong oleh medan itu. Jika matlamatnya ialah analisis menang-kalah, medan itu perlu menggunakan picklist terkawal, diwajibkan hanya pada semakan closed-lost atau peringkat akhir, dan mempunyai laluan "Lain-lain" dengan semakan. Definisi itu perlu berada dalam kamus data, dan pengurus jualan perlu memeriksanya semasa semakan kehilangan.

Medan yang sama boleh sama ada mencipta wawasan atau kekusutan bergantung kepada tadbir urus.

Contoh: menambah risiko pelaksanaan

Kejayaan pelanggan meminta medan risiko pelaksanaan sebelum closed-won.

Ini mungkin medan yang baik, tetapi hanya jika aliran kerja ditakrifkan. Jualan memerlukan contoh nilai risiko. Pengurus perlu memeriksa medan itu sebelum penutupan. Kejayaan pelanggan perlu menggunakannya dalam onboarding. RevOps perlu melaporkan kelengkapan serah tugas.

Jika tiada satu pun daripada itu berlaku, medan itu menjadi satu lagi kotak wajib.

Tadbir urus medan memaksa proses perniagaan menjadi jelas sebelum CRM menyimpan data itu.

Contoh: menambah input pemarkahan AI

Sebuah pasukan mahu menambah medan kerana model pemarkahan AI mungkin menggunakannya kelak.

Permintaan itu memerlukan penelitian tambahan.

Sebelum meluluskan, RevOps perlu bertanya:

• Adakah medan itu ditakrifkan cukup jelas untuk sesuatu model?
• Adakah pengguna akan mengisinya secara konsisten?
• Adakah medan itu fakta yang diperhatikan, pertimbangan pengurus, atau tekaan pengguna?
• Adakah medan itu memperkenalkan bias?
• Bagaimana kualiti akan dipantau?
• Siapa dapat menjelaskan maksud medan itu enam bulan dari sekarang?

Aliran kerja AI menjadikan tadbir urus medan lebih penting, bukan kurang. Jika pemarkahan, penghalaan, ramalan, atau cadangan akaun menggunakan medan CRM, definisi yang tidak jelas menjadi bunyi bising model.

Contoh: menamatkan medan kempen lama

Pemasaran menemui tiga medan kempen daripada model operasi lampau. Satu masih digunakan untuk sumber asal. Satu digunakan untuk laporan yang telah dihentikan. Satu lagi kelihatan pada susun atur lead tetapi tidak lagi mempunyai pemilik.

RevOps tidak sepatutnya menghapuskan ketiga-tiganya sekali gus.

Pertama, petakan laporan dan integrasi. Kemudian sembunyikan medan yang dihentikan daripada susun atur aktif. Kekalkan medan sumber asal jika atribusi sejarah bergantung kepadanya. Kemas kini kamus data. Beritahu pasukan bahawa medan lama yang kelihatan itu tidak lagi digunakan.

Penamatan medan patut mengurangkan kekusutan tanpa merosakkan sejarah.

Kesilapan biasa medan CRM

Menambah medan tanpa definisi. Pengguna mentafsirnya secara berbeza.

Mewajibkan medan terlalu awal. Pengguna meneka atau memasukkan placeholder.

Menggunakan teks apabila kategori diperlukan. Pelaporan menjadi tidak konsisten.

Mengekalkan medan lama kelihatan. Susun atur menjadi sesak dan pengguna mengabaikan medan penting.

Tiada pemilik. Tiada siapa perasan apabila nilai merosot.

Mengubah nilai tanpa komunikasi. Laporan rosak secara senyap.

Membenarkan setiap pasukan mencipta medan tempatan. CRM menjadi koleksi keperluan yang tidak berhubung.

Melangkau penamatan. Medan lama terus menghabiskan perhatian selepas sebab perniagaannya hilang.

Rupa yang baik

Tadbir urus medan yang baik menjadikan CRM terasa lebih ringkas.

Pengguna melihat lebih sedikit medan yang tidak relevan. Medan wajib muncul apabila data itu boleh diketahui. Pengurus memeriksa medan yang sama diukur oleh RevOps. Laporan menggunakan definisi yang didokumenkan. Permintaan medan baharu dinilai berdasarkan keputusan perniagaan, bukan ditambah secara lalai.

CRM menjadi lebih mudah dipercayai kerana setiap medan penting mempunyai tugasnya.

Tadbir urus yang baik turut menjadikan perubahan lebih pantas. Apabila medan mempunyai pemilik dan definisi, RevOps boleh mengemas kini aliran kerja tanpa perlu meneroka semula sebab data itu wujud.

Model kematangan tadbir urus medan

Kebanyakan pasukan boleh beralih daripada medan berselerak kepada tadbir urus terurus tanpa program yang besar. Peralihan utama ialah menjadikan medan membuktikan sebab perniagaannya sebelum ia dilancarkan.

Semakan medan suku tahunan

Setiap suku, semak medan yang menjejaskan ramalan, penghalaan, atribusi, serah tugas, kesihatan pelanggan, dan pelaporan eksekutif.

Tanya:

• Adakah definisi masih sepadan dengan perniagaan?
• Adakah pemilik masih betul?
• Adakah medan itu diwajibkan pada masa yang betul?
• Adakah pengguna mempercayai nilai-nilai itu?
• Adakah pasukan hiliran masih menggunakan data itu?
• Adakah laporan atau automasi masih bergantung kepadanya?
• Perlukah medan itu disembunyikan, disemak semula, digabungkan, atau ditamatkan?

Semakan ini menghalang tadbir urus medan daripada menjadi pintu kelulusan sekali sahaja.

Ia juga memberikan RevOps peluang untuk membuang kerumitan lama sebelum permintaan baharu tiba.

Disiplin itu melindungi penerimaan.

Pakej kelulusan tadbir urus medan

Sebelum meluluskan medan CRM baharu, perlukan:

• Nama dan definisi medan.
• Keputusan perniagaan yang disokong.
• Objek dan peringkat di mana ia berlaku.
• Pemilik.
• Nilai yang dibenarkan.
• Status wajib atau pilihan.
• Laporan dan aliran kerja yang terjejas.
• Sumber kemasukan data.
• Tarikh penamatan atau irama semakan.

Ini menjadikan penciptaan medan lebih sukar dengan cara yang betul. Jika medan itu tidak dapat melepasi pakej ini, ia berkemungkinan menjadi kekusutan.

Soalan Lazim

Siapa yang patut memiliki tadbir urus medan CRM?

RevOps perlu memiliki proses tadbir urus. Pasukan fungsi perlu memiliki maksud perniagaan bagi medan dalam kawasan mereka. Pentadbir sistem perlu memiliki kualiti pelaksanaan dan kawalan perubahan.

Mengapa medan CRM menjadi berselerak?

Medan menjadi berselerak apabila setiap permintaan dianggap tidak berbahaya. Setiap medan menambah beban kognitif, risiko pelaporan, dan kos penyelenggaraan. Tadbir urus menjadikan kos itu kelihatan sebelum medan itu dicipta.

Perlukah setiap medan berada dalam kamus data?

Setiap medan berimpak tinggi perlu didokumenkan. Medan peribadi berisiko rendah mungkin tidak memerlukan dokumentasi penuh, tetapi mana-mana medan yang digunakan dalam pelaporan, automasi, serah tugas, ramalan, atribusi, atau metrik eksekutif perlu mempunyai pemilik dan definisi.

Berapa kerap medan patut disemak?

Medan berimpak tinggi patut disemak setiap suku. Medan bersama lain boleh disemak setiap enam hingga dua belas bulan. Medan wajib baharu patut disemak sejurus selepas pelancaran untuk mengesan kelengkapan palsu dan geseran pengguna.

Ketahui lebih lanjut

• Model Operasi Penerimaan CRM
• Dashboard Revenue Operations
• Audit Proses Hasil
• Sumber Kebenaran untuk Data Hasil