Merancang Data Model CRM Sebelum Menyentuh Software

Sebuah tim penjualan SaaS beranggotakan 40 orang membangun ulang data model CRM mereka dua kali dalam 12 bulan. Build pertama memakan waktu tiga minggu untuk dikonfigurasi. Rebuild kedua terjadi karena mereka menemukan, di pertengahan Q2, bahwa model kontak mereka tidak bisa mendukung beberapa kontak per deal dengan peran yang berbeda. Upaya ketiga, yang dilakukan di atas kertas sebelum menyentuh CRM, telah berjalan tanpa perubahan struktural selama 18 bulan.

Upaya ketiga itu dimulai dengan papan tulis, bukan laptop.

Pelajaran intinya: setiap implementasi CRM yang berantakan terjadi karena seseorang mulai mengklik sebelum berpikir. Kontak vs. Lead vs. Akun vs. Deal: relasi antara objek-objek ini menentukan apa yang bisa Anda laporkan, apa yang bisa Anda otomasi, dan bagaimana Pipeline Anda bekerja. Salah desain dan Anda akan menghabiskan Q3 untuk migrasi data yang dimasukkan di Q1.

Panduan ini memandu Anda merancang data model CRM di atas kertas sebelum mengkonfigurasi satu field pun.

Langkah 1: Daftarkan Objek Bisnis Utama Anda

Mulailah dengan empat objek default yang dikirimkan setiap CRM:

Kontak: Individu yang berinteraksi dengan tim Anda
Perusahaan (Akun): Organisasi tempat kontak berasal
Deal (Peluang): Motion penjualan aktif dengan tanggal close dan nilai
Aktivitas: Panggilan, email, meeting, tugas (catatan interaksi)

Sebelum menambahkan hal lain, validasi bahwa empat ini mencakup 90% dari motion penjualan Anda. Biasanya memang demikian. Godaan untuk menambahkan custom objects sangat kuat. Tahan sampai Anda membuktikan bahwa objek standar tidak bisa menangani use case tersebut.

Custom objects sepadan dengan kompleksitasnya hanya ketika:

Anda melacak sesuatu yang bukan orang, perusahaan, atau deal (misalnya, aset fisik, deliverable proyek, instalasi produk)
Struktur relasinya secara fundamental berbeda dari kontak-perusahaan-deal
Anda memiliki 3+ field yang hanya berlaku untuk entitas ini

Di Salesforce, custom objects kuat tetapi menambah overhead lisensi dan pemeliharaan — panduan Salesforce untuk custom objects mencakup pertimbangan setup dan izin. Di HubSpot, custom objects tersedia di paket Enterprise dan semakin canggih. Di Pipedrive, custom objects tidak ada dengan cara yang sama. Anda menggunakan custom fields pada objek yang ada.

Jika Anda tidak menggunakan Salesforce Enterprise atau HubSpot Enterprise, jangan rancang model Anda di sekitar custom objects. Rancang untuk apa yang didukung CRM.

Langkah 2: Petakan Relasinya

Gambarkan ini sebelum membuka CRM. Anda perlu memahami kardinalitasnya: berapa banyak dari satu objek yang bisa berhubungan dengan berapa banyak objek lainnya.

Relasi standar yang perlu didefinisikan:

Relasi	Tipe	Catatan
Kontak → Perusahaan	Banyak-ke-Satu	Satu kontak milik satu perusahaan (default)
Kontak → Perusahaan	Banyak-ke-Banyak	Satu kontak bekerja dengan beberapa perusahaan (fitur Salesforce Accounts, HubSpot Associations)
Kontak → Deal	Banyak-ke-Banyak	Beberapa kontak bisa ada di satu deal (pembelian komite)
Deal → Perusahaan	Banyak-ke-Satu	Satu deal milik satu perusahaan
Aktivitas → Kontak	Banyak-ke-Satu	Aktivitas dicatat terhadap satu kontak
Aktivitas → Deal	Banyak-ke-Satu	Aktivitas dicatat terhadap satu deal

Pertanyaan yang tidak terduga: bisakah kontak milik beberapa perusahaan? Dalam sebagian besar penjualan B2B, Anda menghadapi ini ketika seseorang adalah anggota dewan di dua perusahaan, atau ketika Anda menjual ke holding company dengan beberapa anak perusahaan.

Salesforce menangani ini dengan Account Relationships dan Contact Roles. HubSpot menambahkan dukungan multi-asosiasi pada 2022 — dokumentasi HubSpot tentang asosiasi menjelaskan cara memberi label tipe relasi antar objek. Pipedrive menanganinya dengan kurang elegan. Anda bisa mengasosiasikan seseorang dengan beberapa deal, tetapi perusahaan utama bersifat tunggal.

Jika motion penjualan Anda secara rutin melibatkan kontak yang mencakup beberapa akun, rancang model Anda di sekitar itu sebelum dikonfigurasi. Jika jarang, tangani sebagai kasus tepi dalam catatan Anda daripada membangun kompleksitas ke dalam data model untuk itu.

Langkah 3: Tentukan Apa yang Ada di Setiap Objek

Untuk setiap objek, daftarkan field-nya. Jangan lewati langkah ini demi "kita selesaikan saat konfigurasi." Tidak akan. Anda akan menambahkan field secara reaktif dan akhirnya punya 80 field pada bulan ketiga.

Untuk setiap field, definisikan:

Nama: Apa namanya. Konsistenlah dengan konvensi penamaan dan putuskan Title Case vs. sentence case sekarang.
Tipe: Teks, picklist, angka, tanggal, checkbox, formula, lookup
Wajib?: Ya atau Tidak. Pertahankan daftar ini singkat.
Tujuan: Untuk dilaporkan, disegmentasi, memicu otomasi, atau ditampilkan ke rep

Definisi objek Kontak contoh mungkin terlihat seperti ini:

Field	Tipe	Wajib	Tujuan
Nama Depan	Teks	Ya	Tampilan
Nama Belakang	Teks	Ya	Tampilan
Email	Teks	Ya	Sinkronisasi email, otomasi
Telepon	Teks	Tidak	Tampilan
Jabatan	Teks	Tidak	Tampilan
Sumber Lead	Picklist	Ya	Pelaporan, otomasi
Status Lead	Picklist	Ya	Routing, pelaporan
Kesesuaian ICP	Picklist	Tidak	Segmentasi
Tanggal Aktivitas Terakhir	Tanggal (sistem)	—	Dibuat sistem
Pemilik Kontak	Lookup → Pengguna	Ya	Routing

Dan objek Deal:

Field	Tipe	Wajib	Tujuan
Nama Deal	Teks	Ya	Tampilan
Tahap Pipeline	Picklist	Ya	Pipeline, forecasting
Tanggal Close	Tanggal	Ya	Forecasting
Nilai Deal	Mata Uang	Ya	Pelaporan
Tipe Deal	Picklist	Ya	Segmentasi
Alasan Kalah	Picklist	Tidak (wajib saat close-lost)	Pelaporan
Akun	Lookup → Perusahaan	Ya	Relasi
Kontak Utama	Lookup → Kontak	Ya	Relasi
Kategori Forecast	Picklist	Tidak	Forecasting

Inilah tepatnya pekerjaan yang mencegah pembicaraan custom fields menjadi kacau. Lihat panduan custom fields untuk framework keputusan setiap permintaan field.

Langkah 4: Bangun Nilai Picklist Bersama Tim

Di sinilah data buruk dimulai: satu rep mengetik "Jasa Keuangan" di field industri, rep lain mengetik "Fintech," rep lain mengetik "Perbankan & Keuangan." Sekarang laporan industri Anda tidak berguna.

Picklist memaksakan konsistensi. Tetapi hanya berfungsi jika nilainya dirancang untuk pelaporan, bukan hanya entri data.

Picklist utama yang perlu didefinisikan sebelum go-live:

Sumber Lead: Di mana kontak masuk ke CRM. Contoh nilai: Inbound Web, Outbound SDR, Referral, Mitra, Acara, Unduhan Konten, Iklan Berbayar, Trial Signup. Pertahankan ini di tingkat sumber, bukan "Iklan Facebook - Nama Kampanye - Maret 2026." Nilai tingkat sumber tetap bersih. Tingkat kampanye ada di tool atribusi marketing Anda.

Industri: Gunakan taksonomi yang konsisten. Mulailah dengan 10-12 nilai dan tolak permintaan untuk menambahkan lebih banyak dalam 90 hari pertama. SaaS, Jasa Keuangan, Kesehatan, Manufaktur, Jasa Profesional, Ritel, Media, Pendidikan, Non-Profit, Lainnya.

Alasan Kalah: Ini penting untuk pembelajaran tetapi hampir selalu berantakan. Alasan kalah yang baik jujur dan dapat ditindaklanjuti: Tidak Ada Anggaran, Pilih Kompetitor (disebutkan namanya), Tidak Ada Keputusan, Waktu, Tidak Cocok, Menghilang. Hindari opsi samar seperti "Lainnya" sebagai catchall.

Tahap Pipeline: Definisikan ini dengan cermat. Lihat panduan tahap Pipeline untuk cara membangun tahap berdasarkan milestone pembeli daripada aktivitas rep.

Tipe Deal: Bisnis Baru, Ekspansi, Perpanjangan, Reaktivasi. Jika Anda hanya menjual satu jenis, lewati ini. Jika Anda memiliki beberapa motion, field ini memisahkan Pipeline Anda menjadi Funnel yang berbeda.

Untuk setiap picklist, definisikan: siapa yang memiliki nilainya, bagaimana nilai baru ditambahkan (proses persetujuan vs. terbuka), dan apa yang terjadi pada nilai lama ketika tidak lagi akurat (arsip, bukan hapus).

Langkah 5: Rancang untuk Pelaporan, Bukan Hanya Entri Data

Berikut tesnya untuk setiap field: jika Anda tidak bisa mengkuerinya atau mengelompokkan berdasarkannya dalam laporan, jangan simpan sebagai teks bebas.

"Catatan pelanggan" sebagai field teks berguna untuk rep yang membaca konteks sebelum panggilan. Tidak berguna untuk analisis agregat apa pun. "Pain Point" sebagai field teks bebas berarti Anda tidak akan pernah tahu bahwa 60% deal Anda menyebut "proses manual" sebagai masalah utama. Tidak ada yang bisa mengurai 2.000 entri teks.

Ketika seseorang meminta field teks bebas, tanyakan: apakah Anda pernah ingin menghitung berapa banyak deal yang termasuk dalam kategori berbeda dari field ini? Jika ya, itu harus menjadi picklist. Jika memang narasi kontekstual, teks tidak apa-apa. Tetapi hanya milik di bagian catatan atau catatan aktivitas.

Field formula berguna tetapi memerlukan pemeliharaan. Jika nilai field bisa dihitung dari field lain (misalnya, Hari dalam Tahap = Hari Ini - Tanggal Masuk Tahap), gunakan formula. Tetapi field formula di Salesforce memiliki batas, dan di HubSpot memerlukan Operations Hub Professional — dokumentasi properti formula HubSpot menunjukkan apa yang didukung di setiap tingkat. Ketahui kemampuan field formula CRM Anda sebelum merancang model yang bergantung padanya.

Langkah 6: Dokumentasikan Model dalam Schema Sheet

Sebelum mengkonfigurasi apa pun, dokumentasikan desain Anda dalam spreadsheet sederhana. Satu tab per objek, kolom untuk: nama field, tipe field, wajib, nilai (untuk picklist), dan tujuan.

Schema sheet dasar memiliki:

Tab Definisi Objek: Daftar semua objek, tujuannya, dan apakah standar atau custom
Tab Relasi: Setiap relasi objek-ke-objek dengan kardinalitas yang dicatat
Tab Definisi Field: Satu per objek dengan format tabel di atas
Tab Nilai Picklist: Setiap picklist dan setiap nilai, dengan catatan siapa yang memilikinya

Dokumen ini menjadi spesifikasi implementasi Anda. Admin CRM Anda mengkonfigurasi darinya. Tim Anda meninjaunya sebelum go-live. Manajer Anda bisa membacanya tanpa membuka CRM.

Simpan schema sheet di shared drive, bukan hanya di kepala Anda. Admin CRM berubah. Diri Anda di masa depan akan berterima kasih.

Perbedaan Berdasarkan CRM

Sebelum mengunci skema Anda, ada baiknya meninjau bagaimana data model Rework dibandingkan dengan struktur objek default Salesforce — terutama jika Anda mempertimbangkan opsi yang lebih ringan.

Salesforce: Data model Salesforce adalah yang paling kuat dan paling kompleks. Objek standar adalah Lead, Kontak, Akun, dan Peluang. Proses konversi Lead-ke-Kontak memerlukan desain yang disengaja. Kapan sebuah Lead menjadi Kontak dengan Akun dan Peluang yang terkait? Transisi ini adalah sumber kebingungan yang umum. Custom objects dan relasi custom tersedia di sebagian besar tingkat lisensi tetapi memerlukan keahlian Admin atau Developer untuk dikonfigurasi dengan bersih.

HubSpot: Model default HubSpot adalah Kontak, Perusahaan, Deal, dan Tiket. Fitur Associations (tersedia di semua tingkat berbayar) memungkinkan relasi multi-objek tetapi memiliki batas pada jenis asosiasi di tingkat lebih rendah. HubSpot tidak memiliki objek Lead secara default. Kontak mengisi peran tersebut, yang menyederhanakan model tetapi memerlukan field Lead Status dan Lifecycle Stage yang jelas untuk melacak perkembangan. Custom objects hanya tersedia di Enterprise.

Pipedrive: Pipedrive menjaga model tetap sederhana: Orang, Organisasi, Deal, Aktivitas. Tidak mendukung custom objects. Relasi bersifat langsung dan ada lebih sedikit fleksibilitas tetapi juga lebih sedikit yang bisa salah. Jika motion penjualan Anda relatif standar, kesederhanaan Pipedrive adalah sebuah fitur. Jika Anda memerlukan hierarki akun yang kompleks atau peran kontak pada deal, Anda akan mencapai batasnya.

Close: Close menggunakan Lead sebagai objek tingkat teratas, dengan Kontak di bawahnya. Ini berbeda dari sebagian besar CRM dan memerlukan penyesuaian jika Anda bermigrasi dari Salesforce atau HubSpot. Modelnya sangat cocok untuk inside sales tetapi kurang fleksibel untuk struktur akun enterprise yang kompleks.

Kesalahan Umum

Terlalu banyak custom fields di hari pertama. Rata-rata CRM memiliki 80% field yang tidak digunakan dalam 6 bulan. Mulailah lean, 15-20 field per objek, dan tambahkan hanya ketika ada kebutuhan pelaporan atau otomasi yang terbukti. Anda selalu bisa menambahkan field. Membersihkan 60 field yang tidak digunakan dan data buruk di dalamnya adalah sebuah proyek.

Picklist yang tidak terkontrol. Ketika beberapa orang bisa menambahkan nilai picklist tanpa proses tata kelola, Anda mendapatkan 12 versi "Jasa Keuangan" di field industri. Tentukan kepemilikan picklist sebelum go-live. Satu orang menyetujui nilai baru.

Membangun untuk kasus tepi. Satu rep memiliki deal dengan empat kontak, masing-masing dengan peran berbeda. Itu nyata, tetapi bukan kasus umum. Jangan rancang seluruh data model Anda di sekitar pengecualian. Tangani kasus umum dengan bersih, dan dokumentasikan cara menangani kasus tepi secara manual.

Tidak melibatkan orang yang tepat dalam tinjauan skema. Schema sheet harus ditinjau oleh setidaknya satu rep (apakah ini cocok dengan cara saya bekerja?), satu manajer (bisakah saya membuat laporan yang saya butuhkan?), dan satu orang keuangan (apakah data deal mendukung forecasting kami?). RevOps membangun model secara terpisah adalah cara mendapatkan model yang memuaskan tool tetapi tidak bisnis.

Apa yang Harus Dilakukan Selanjutnya

Ambil schema sheet yang telah Anda buat dan jalankan oleh tiga orang: satu rep, satu manajer, dan satu orang keuangan atau operasi. Berikan masing-masing satu pertanyaan untuk dijawab: "Berdasarkan model ini, bisakah Anda melakukan hal yang paling sering Anda lakukan dalam workflow CRM Anda?" Jika ada yang mengatakan tidak, perbaiki modelnya sebelum membuka software.

Setelah itu, baca panduan custom fields untuk mendapatkan framework keputusan setiap permintaan field yang masuk selama implementasi. Dan akan ada banyak permintaan.

CRM Implementation Guide