Field Wajib vs Field Berguna: Pencatatan Data CRM Tanpa Teater Rep

Tidak semua field yang berguna harus dijadikan wajib.

Field wajib menciptakan hambatan. Jika field tersebut tidak mendukung perutean, kualifikasi, forecast, serah terima, kepatuhan, atau pengiriman, memaksa pengguna untuk mengisinya sering kali justru menghasilkan data yang lebih buruk.

Riset keselarasan teknologi RevOps dari Forrester berguna di sini karena persyaratan field bukan sekadar keputusan admin lokal. Persyaratan ini memengaruhi teknologi revenue dan workflow bersama. Riset kepercayaan forecast dari Gartner juga menunjukkan mengapa kualitas data dan kepercayaan forecast sangat penting.

Fakta operasional utama

• Sebuah field seharusnya wajib hanya ketika bisnis menggunakannya untuk mengambil keputusan nyata atau memicu workflow nyata.
• Field wajib harus didasarkan pada tahap (stage). Field yang tidak masuk akal saat penangkapan lead bisa jadi penting sebelum pembuatan opportunity atau serah terima closed-won.
• Field yang berguna bisa tetap opsional, diperkaya secara otomatis, ditangkap belakangan, atau dipindahkan ke peninjauan manajer alih-alih entri data oleh rep.
• Tata kelola field harus menyeimbangkan kualitas keputusan dengan hambatan bagi pengguna. Terlalu banyak field wajib sering menghasilkan kelengkapan semu, bukan data yang lebih baik.

Tabel keputusan field

Kaitkan ini dengan Tata Kelola Field CRM.

Uji keputusan

Ajukan satu pertanyaan sebelum mewajibkan sebuah field:

Keputusan apa yang gagal jika field ini kosong?

Jika jawabannya jelas, field tersebut mungkin layak diwajibkan. Jika jawabannya kabur, biarkan tetap opsional, otomatiskan, atau hapus.

Alasan yang kuat:

• Merutekan lead ini
• Menerima atau menolak SQL ini
• Membuat opportunity
• Meninjau forecast
• Menyerahterimakan pelanggan
• Memulai onboarding
• Mengeskalasi risiko perpanjangan
• Melapor ke bagian keuangan

Alasan yang lemah:

• Mungkin nanti ada yang membutuhkannya
• Akan bagus untuk analisis
• Sebuah template dashboard mencantumkannya
• Seorang pemimpin pernah memintanya sekali

Uji keputusan ini harus tertulis dalam proses permintaan field. Jika pemohon tidak bisa menyebutkan keputusan, pemilik, tahap, serta laporan atau workflow yang terpengaruh, field tersebut belum siap dijadikan wajib.

Ini melindungi kegunaan CRM. Rep dan manajer bisa menerima field wajib ketika alasannya terlihat jelas: perutean, forecast, serah terima, penagihan, kepatuhan, atau pengiriman ke pelanggan. Mereka kehilangan kepercayaan ketika field terasa seperti pajak rasa ingin tahu semata.

Wajib pada tahap yang tepat

Sebuah field bisa berguna di awal tapi baru wajib belakangan.

Contoh:

Ini mencegah pengguna menebak jawaban sebelum mereka benar-benar tahu.

Field opsional

Field opsional tetap bisa bernilai.

Gunakan field opsional ketika:

• Data berguna tapi tidak dibutuhkan untuk workflow.
• Data bisa ditangkap belakangan.
• Data terlalu bergantung pada penilaian subjektif.
• Data memiliki tingkat keyakinan rendah.
• Data hanya dibutuhkan untuk analisis sesekali.

Opsional bukan berarti diabaikan. Artinya RevOps memilih untuk tidak menciptakan hambatan sebelum field tersebut mendukung sebuah keputusan.

Otomasi dan enrichment

Beberapa field yang berguna sebaiknya diotomatiskan:

• Ukuran perusahaan
• Industri
• Wilayah
• Situs web
• Sinyal teknologi
• Data pendanaan
• Ambang batas penggunaan

Otomasi tetap perlu aturan tingkat keyakinan. Enrichment dengan tingkat keyakinan rendah bisa menghasilkan perutean dan pelaporan yang buruk.

Teater rep

Teater rep terjadi ketika pengguna mengisi field hanya untuk memuaskan sistem.

Tanda-tandanya:

• "Tidak diketahui" menjadi jawaban umum.
• Nilai picklist mengelompok pada opsi yang paling mudah.
• Field wajib diisi dengan placeholder.
• Manajer mengabaikan field tersebut.
• Laporan yang menggunakan field itu tidak dipercaya.

Ketika ini terjadi, hapus persyaratan wajibnya atau rancang ulang workflow-nya.

Irama peninjauan field

Tinjau field wajib setiap kuartal.

Tanyakan:

• Apakah field ini digunakan?
• Apakah akurat?
• Apakah mendukung sebuah keputusan?
• Apakah wajib pada tahap yang tepat?
• Bisakah diotomatiskan?
• Haruskah dipensiunkan?

Field wajib harus membuktikan kelayakannya.

Daftar periksa kesiapan

Sebelum mewajibkan sebuah field:

• Keputusan sudah jelas.
• Tahap sudah tepat.
• Pemilik sudah ditentukan.
• Nilai yang diperbolehkan sudah didefinisikan.
• Pengguna tahu cara menjawabnya.
• Manajer memeriksa kualitasnya.
• Laporan menggunakan field tersebut.
• Rencana pembersihan sudah ada.

Field wajib terbaik terasa jelas bagi pengguna karena waktu dan tujuannya sesuai dengan pekerjaan.

Field wajib yang baik

Field wajib yang baik mendukung keputusan jangka pendek: merutekan lead ini, menerima SQL ini, meninjau forecast ini, menyerahterimakan pelanggan ini, atau memperpanjang akun ini.

Field wajib yang buruk

Field wajib yang buruk ada karena suatu saat seseorang pernah menginginkan sebuah laporan. Jika tidak ada yang menggunakan datanya, field tersebut mengajarkan pengguna bahwa pekerjaan CRM hanyalah teater.

Pelajaran itu mahal harganya. Begitu pengguna percaya CRM meminta data yang tidak berarti, mereka berhenti mempercayai field yang benar-benar penting juga.

Kerangka keputusan

Gunakan empat kategori:

Ini menjaga percakapan tetap praktis. Perdebatannya bukan apakah sebuah field menarik. Perdebatannya adalah apakah bisnis sebaiknya meminta seorang manusia untuk mengisinya.

Contoh

Sumber lead. Wajib saat pembuatan karena atribusi, perutean, dan pelaporan funnel bergantung padanya.

Use case. Berguna selama discovery, wajib sebelum serah terima closed-won karena CS membutuhkan konteksnya.

Kompetitor. Berguna ketika kompetisi sudah diketahui, tapi sering kali buruk jika dijadikan field wajib di tahap awal.

Industri. Sering kali lebih baik diotomatiskan atau diperkaya, lalu ditinjau ketika pelaporan segmen menjadi penting.

Sinyal ekspansi. Wajib ketika sebuah opportunity ekspansi dibuat, opsional sebelum sinyal tersebut terkualifikasi.

Waktu field wajib

Waktu yang salah menghasilkan data yang buruk.

Jika sebuah field diwajibkan sebelum pengguna bisa mengetahui jawabannya, pengguna akan menebak. Jika field diwajibkan setelah keputusan sudah terjadi, bisnis kehilangan kendali. Waktu yang tepat adalah saat data tersebut menjadi bisa diketahui dan diperlukan.

Cara mengurangi hambatan

RevOps bisa mengurangi hambatan dengan:

• Menggunakan nilai default secara hati-hati
• Mengotomatiskan nilai yang sudah diketahui
• Membatasi jumlah field wajib per tahap
• Mengelompokkan field berdasarkan workflow
• Menghapus field dari tata letak halaman ketika tidak relevan
• Menggunakan persyaratan bersyarat
• Melatih manajer untuk memeriksa kualitas

Tujuannya bukan mengurangi field sebanyak mungkin. Tujuannya adalah mengurangi entri yang tidak berarti.

Tinjauan kualitas

Tinjau field wajib berdasarkan kualitas, bukan sekadar tingkat kelengkapan.

Kelengkapan bisa mencapai 100 persen sementara kualitasnya buruk. Waspadai nilai placeholder, nilai "tidak diketahui", default yang berulang, dan nilai yang tidak dipercaya manajer.

Jika kualitasnya buruk, perbaiki waktunya, nilai yang diperbolehkan, pelatihan, atau kepemilikannya.

Pertanyaan tata kelola

Sebelum menyetujui sebuah field wajib:

• Siapa yang membutuhkannya?
• Keputusan apa yang bergantung padanya?
• Kapan pengguna bisa mengetahuinya?
• Apa saja nilai yang valid?
• Siapa yang memeriksa kualitasnya?
• Apa yang terjadi jika salah?
• Bisakah otomasi mengisinya?

Jika jawabannya lemah, jangan jadikan wajib.

Aturan tata kelola

Field wajib harus melindungi keputusan. Field berguna harus mendukung pembelajaran. Field opsional tidak boleh berpura-pura menjadi kontrol. Perbedaan itu menjaga data CRM tetap bisa digunakan.

Rencana peluncuran

Audit field wajib berdasarkan objek.

Untuk setiap field wajib, tanyakan:

• Keputusan apa yang menggunakannya?
• Tahap mana yang mewajibkannya?
• Siapa yang memeriksa kualitasnya?
• Apa yang terjadi jika kosong?
• Apa yang terjadi jika salah?
• Bisakah diotomatiskan?
• Haruskah dijadikan opsional?

Kemudian kelompokkan field ke dalam empat kelompok:

Audit ini sering kali cepat menghilangkan hambatan.

Scorecard field wajib

Pantau:

• Tingkat kelengkapan
• Tingkat "tidak diketahui"
• Tingkat placeholder
• Skor kepercayaan manajer
• Laporan yang menggunakan field tersebut
• Workflow yang menggunakan field tersebut
• Keluhan pengguna
• Waktu yang dihabiskan untuk mengisi data

Kelengkapan saja tidak cukup. Sebuah field bisa lengkap tapi tetap tidak berguna.

Contoh waktu per tahap

Tahap lead:

• Wajib: sumber, pemilik, status
• Opsional atau otomatis: industri, jumlah karyawan, detail enrichment

Tahap opportunity:

• Wajib: nilai, tanggal closing, tahap, langkah berikutnya
• Wajib belakangan: pembeli ekonomi, proses keputusan, risiko

Closed-won:

• Wajib: kriteria keberhasilan, catatan serah terima, cakupan kontrak, tanggal perpanjangan

Risiko perpanjangan:

• Wajib: alasan risiko, pemilik, tindakan berikutnya

Waktu seperti ini menjaga entri data tetap selaras dengan pekerjaan.

Pemeriksaan manajer

Manajer harus memeriksa kualitas field wajib.

Jika field wajib terisi tapi manajer tidak pernah merujuknya, pengguna akan menyadarinya. Field itu menjadi teater. Ketika manajer menggunakan jawabannya dalam peninjauan pipeline, forecast, dan serah terima, pengguna memahami mengapa data itu penting.

Kehati-hatian otomasi

Otomasi bisa mengurangi entri manual tapi tetap membutuhkan tata kelola.

Field yang terisi otomatis harus menampilkan tingkat keyakinan atau sumbernya ketika digunakan untuk keputusan penting. Jika data enrichment merutekan sebuah lead ke tim yang salah, otomasi menciptakan masalah yang sama seperti entri manual yang buruk.

Daftar periksa kehati-hatian otomasi

Kebijakan field wajib dikatakan sehat ketika:

• Pengguna memahami mengapa setiap field penting.
• Field wajib pada tahap yang tepat.
• Manajer memeriksa kualitasnya.
• Otomasi mengisi hal-hal yang seharusnya tidak dikerjakan manusia.
• Field opsional tetap tersedia untuk pembelajaran.
• Field yang buruk dipensiunkan.

Tujuannya adalah lebih sedikit field yang tidak berarti dan data keputusan yang lebih baik.

Skenario operasional

Skenario: pimpinan sales ingin "langkah berikutnya" diwajibkan pada setiap opportunity.

Itu mungkin masuk akal, tapi waktu dan kualitas tetap penting. Langkah berikutnya harus terkini, spesifik, dan terkait dengan tindakan pelanggan. Jika pengguna hanya menulis "follow up" sekadar untuk lolos validasi, persyaratan itu tidak berfungsi. Pemeriksaan manajer tetap dibutuhkan.

Skenario: marketing ingin persona diwajibkan pada lead.

Jika persona menentukan perutean atau nurture, itu bisa berguna. Jika hanya ditebak secara manual dari pengisian formulir, itu bisa menghasilkan data yang buruk. RevOps harus memutuskan apakah enrichment, progressive profiling, atau penangkapan opsional lebih baik.

Skenario: CS ingin kriteria keberhasilan diwajibkan saat closed-won.

Itu biasanya persyaratan yang kuat karena onboarding bergantung padanya. Tapi sebaiknya diwajibkan saat serah terima, bukan saat pembuatan opportunity di tahap awal.

Anggaran hambatan field

Setiap workflow memiliki anggaran hambatan.

Jika seorang rep harus mengisi sepuluh field untuk menggerakkan sebuah deal, kualitasnya akan menurun. Jika seorang CSM harus mengisi formulir panjang sebelum setiap pembaruan risiko, risiko bisa jadi kurang terlaporkan. RevOps sebaiknya menyimpan field wajib hanya untuk momen di mana datanya sepadan dengan hambatan yang ditimbulkan.

Strategi field berguna

Field yang berguna bisa ditangkap melalui:

• Otomasi
• Enrichment
• Prompt opsional untuk manajer
• Catatan panggilan
• Formulir pelanggan
• Penggunaan produk
• Catatan CS
• Pembersihan berkala

Tidak semua data yang berguna perlu mengganggu workflow inti.

Aturan pensiun

Jika sebuah field wajib tidak diperiksa, dilaporkan, atau digunakan dalam workflow selama satu kuartal penuh, tinjau kembali. Jika tidak ada pemilik yang membelanya dengan keputusan nyata, hapus persyaratan wajibnya.

Peringatan aturan pensiun

Field wajib adalah kontrak kepercayaan dengan pengguna. Ketika RevOps mewajibkan sebuah field, itu berarti bisnis berjanji akan menggunakan jawabannya. Melanggar kontrak itu membuat program data di masa depan lebih sulit.

Contoh tinjauan

Jika "budget terkonfirmasi" diwajibkan terlalu dini, rep mungkin akan menebak. Lebih baik: jadikan opsional saat discovery, ditinjau manajer saat solution fit, dan diwajibkan sebelum commit jika proses forecast bergantung padanya.

Jika "risiko customer success" diwajibkan sebelum closed-won, rep mungkin belum tahu. Lebih baik: wajibkan risiko implementasi dan janji yang dibuat saat serah terima, lalu biarkan CS memperbarui risiko pelanggan setelah onboarding dimulai.

Jika "industri" dibutuhkan untuk segmentasi, jangan minta rep mengetiknya secara manual jika enrichment bisa mengisinya. Entri manual sebaiknya disimpan untuk hal-hal yang memang lebih diketahui manusia dibanding sistem.

Sprint pembersihan field wajib

Jalankan sprint pembersihan:

1. Daftar semua field wajib berdasarkan objek.
2. Identifikasi keputusan bisnis untuk masing-masing.
3. Periksa tingkat kelengkapan dan kualitas.
4. Tanyakan kepada manajer apakah mereka memeriksanya.
5. Pindahkan field yang lemah ke opsional atau otomatis.
6. Pindahkan persyaratan yang terlalu dini ke tahap berikutnya.
7. Perbarui deskripsi field dan kamus data.
8. Komunikasikan perubahannya.

Ini sering kali cepat meningkatkan adopsi karena pengguna merasakan CRM menjadi lebih ringan.

Seperti apa yang baik

Kebijakan field wajib yang baik terasa selaras dengan workflow. Pengguna memahami mengapa field itu muncul. Manajer menggunakan jawabannya. Laporan bergantung padanya. RevOps memantau kualitasnya. Ketika sebuah field tidak lagi memenuhi standar itu, persyaratannya ditinjau ulang.

Aturan hambatan field

Jangan mencampuradukkan data yang tersedia dengan data yang wajib. RevOps sebaiknya mengumpulkan data yang cukup untuk menjalankan bisnis, bukan data sebanyak-banyaknya sampai sistem justru melatih pengguna untuk berpura-pura lengkap.

Daftar periksa pembersihan field

Sebelum sebuah field dijadikan wajib, pastikan:

• Field tersebut mendukung keputusan nyata.
• Pengguna bisa mengetahui jawabannya pada tahap tersebut.
• Nilai yang diperbolehkan sudah jelas.
• Pemiliknya sudah ditentukan.
• Manajer akan memeriksa kualitasnya.
• Laporan atau workflow bergantung padanya.
• Field tersebut terdokumentasi dalam kamus data.
• Otomasi sudah dipertimbangkan lebih dulu.

Jika ada jawaban yang lemah, tunda persyaratannya. Field opsional yang berguna lebih baik daripada field wajib yang mengajarkan pengguna untuk mengisi data berkualitas rendah.

Kebijakan ini dikatakan sehat ketika pengguna bisa menebak mengapa sebuah field diwajibkan sebelum RevOps menjelaskannya. Artinya field itu muncul pada momen yang tepat, mendukung keputusan yang terlihat jelas, dan diperiksa oleh manajer yang peduli dengan jawabannya.

Itulah standar yang harus dijaga.

Selain itu hanya menciptakan hambatan yang bisa dihindari.

Model siklus hidup field

Field seharusnya memiliki siklus hidup. Field diusulkan, disetujui, diluncurkan, ditinjau, dan terkadang dipensiunkan.

Model ini mencegah field berkembang biak tanpa kendali. Banyak CRM menjadi sulit digunakan karena field mudah ditambahkan tapi sulit dihapus. RevOps sebaiknya menjadikan penghapusan sebagai bagian dari tata kelola sejak awal.

Tahap peninjauan sangat penting. Field wajib dengan tingkat kelengkapan tinggi tapi kepercayaan rendah bukanlah keberhasilan. Pengguna mungkin mengisinya karena sistem memblokir mereka, sementara manajer mengabaikan nilainya karena tidak akurat. Pantau baik tingkat kelengkapan maupun penggunaannya. Jika tidak ada yang menggunakan field tersebut untuk mengambil keputusan, field itu tidak seharusnya tetap wajib.

Tanggung jawab pemilik field

Setiap field wajib harus memiliki pemilik.

Pemilik harus mendefinisikan:

• Makna bisnis
• Nilai yang diperbolehkan
• Tahap wajib
• Ambang batas kualitas data
• Laporan yang terpengaruh
• Workflow yang terpengaruh
• Irama peninjauan
• Kriteria pensiun

RevOps bisa mengatur prosesnya, tapi tidak boleh menciptakan makna bisnis sendirian. Sales harus memiliki makna proses sales. CS harus memiliki makna risiko pelanggan. Finance harus memiliki makna perencanaan dan penagihan. Marketing harus memiliki makna sumber dan campaign. RevOps membuat makna-makna itu cukup konsisten untuk sistem revenue bersama.

Contoh field wajib berdasarkan workflow

Field wajib terbaik muncul pada momen ketika workflow membutuhkannya.

Waktu seperti ini menghindari kesalahan umum: mewajibkan segalanya pada momen paling awal yang mungkin. Persyaratan yang terlalu dini sering menghasilkan data buruk karena pengguna belum tahu jawabannya. Persyaratan yang belakangan bisa jauh lebih akurat karena pengguna sudah mencapai titik di mana informasinya nyata.

Sebagai contoh, seorang rep mungkin belum tahu budget pada discovery pertama. Tapi sebelum sebuah deal masuk commit, budget dan jalur procurement bisa jadi penting. Seorang CSM mungkin belum tahu risiko churn saat onboarding dimulai. Tapi ketika perpanjangan sudah berada dalam jangka waktu tertentu, kategori risiko dan tindakan berikutnya harus terlihat jelas.

Field wajib sebaiknya mengikuti kematangan bukti.

Paket keputusan field

Sebelum menjadikan sebuah field wajib, jawab:

Ini mengubah field wajib dari teater rep menjadi desain operasional. Jika sebuah field tidak memiliki keputusan, pemilik, waktu, atau konsekuensi, field itu sebaiknya tetap opsional atau dihapus.

FAQ

Siapa yang memutuskan field wajib?

RevOps sebaiknya mengatur keputusan ini dengan masukan dari tim yang menggunakan field tersebut.

Kapan sebuah field seharusnya menjadi wajib?

Pada tahap ketika data tersebut menjadi diperlukan, bukan lebih awal dari itu.

Pelajari lebih lanjut

• Model Operasional Adopsi CRM
• Kamus Data Pendapatan
• Manajemen Perubahan CRM