CRM mengenal prospek, aktivitas penjualan, dan hubungan pelanggan. Billing mengenal akun penagihan, invoice, pembayaran, serta saldo. Ketika keduanya menyimpan nama, alamat, status, dan identifier yang tampak sama, pertanyaan “mana sumber kebenaran?” tidak bisa dijawab dengan memilih satu sistem untuk seluruh data.
Pertahankan riwayat keputusan ketika authority berubah. Merger, migrasi billing, atau proses verifikasi baru dapat memindahkan ownership atribut. Effective date dan versi policy mencegah event lama dinilai dengan aturan baru tanpa sengaja, sekaligus membantu audit menjelaskan mengapa nilai tertentu dipilih pada saat transaksi terjadi.
Source of truth bukan kompetisi satu pemenang
CRM dapat menjadi otoritas nama kontak dan owner penjualan, sementara billing menjadi otoritas legal entity, invoice address, tax identifier, dan payment status. Bahkan satu atribut dapat memiliki fase: alamat yang diusulkan di CRM belum menjadi alamat penagihan sampai melewati verifikasi. Menyalin nilai terbaru berdasarkan timestamp mengabaikan proses tersebut.
Mulailah dari keputusan bisnis, bukan kemampuan API. Siapa yang boleh mengubah atribut? Validasi apa yang harus selesai? Apakah perubahan berlaku surut? Sistem mana yang mengeluarkan identifier? Jawaban membentuk data contract dan workflow; platform integrasi tidak seharusnya menciptakan authority sendiri.
Buat matriks ownership tingkat field
| Data | Otoritas umum | Arah | Catatan keputusan |
|---|---|---|---|
| Lead dan opportunity | CRM | Keluar bila diperlukan | Bukan akun billable sebelum konversi |
| Legal entity | Billing/master resmi | Ke CRM | Perlu verifikasi dan audit |
| Kontak pemasaran | CRM | Selektif | Ikuti consent dan privacy |
| Invoice/payment status | Billing | Ke CRM sebagai read-only | Jangan diedit sales |
| Account manager | CRM | Ke billing bila relevan | Bukan owner finansial |
Tabel ini hanya contoh pola, bukan aturan universal. Nama field, kewenangan, dan privacy boundary harus divalidasi pada organisasi serta vendor masing-masing. Cantumkan juga klasifikasi data, retensi, masking, dan consumer yang boleh menerima atribut.
Identity resolution adalah fondasi sinkronisasi
Email bukan selalu identifier stabil: dapat berubah, dipakai bersama, atau berbeda per kontak. Nama perusahaan juga tidak unik. Buat cross-reference antara ID CRM dan ID billing setelah proses matching yang disetujui. Simpan provenance dan status match. Jangan melakukan merge otomatis untuk kandidat ambigu yang dapat menggabungkan data dua pelanggan.
- Gunakan ID internal immutable pada masing-masing sistem dan tabel referensi lintas sistem.
- Pisahkan person, organization, billing account, dan contract sebagai entitas berbeda.
- Tentukan aturan create, link, merge, split, dan deactivation.
- Jaga raw PII dari log, trace, prompt, dan sampel pengujian.
- Sediakan antrean review manusia untuk match yang tidak pasti.
Tangani konflik, loop, dan event di luar urutan
Sinkronisasi dua arah mudah membentuk loop: CRM memperbarui billing, billing mengirim perubahan yang sama kembali, lalu keduanya terus menulis. Sertakan origin, correlation ID, versi atau waktu sumber, dan aturan untuk mengabaikan echo. Timestamp hanya berguna bila clock, timezone, dan arti “updated” konsisten; version number dari sumber sering lebih aman.
Event dapat tiba terlambat atau dua kali. Consumer perlu idempoten dan mampu menolak versi lama. Untuk konflik yang tidak dapat diselesaikan otomatis, simpan kedua nilai, provenance, alasan, serta route review. “Last write wins” harus menjadi keputusan eksplisit untuk atribut berisiko rendah, bukan default seluruh data.
Pola workflow CRM–billing
- Terima perubahan.
Validasi event, source, versi, dan kontrak sebelum mapping.
- Cari cross-reference.
Gunakan ID stabil; arahkan kandidat ambigu ke review.
- Terapkan ownership.
Pilih hanya field yang boleh mengalir dalam arah tersebut.
- Tulis idempoten.
Gunakan upsert/conflict key yang telah diverifikasi atau API tujuan yang sesuai.
- Catat dan rekonsiliasi.
Simpan correlation/status dan jalankan pemeriksaan berkala antar-sistem.
Untuk perubahan yang menyentuh dua database, transaksi global bukan asumsi aman. Gunakan Saga dengan kompensasi bila benar-benar dibutuhkan, dan akui bahwa API eksternal tidak dapat di-rollback bersama database. Desain state yang dapat direkonsiliasi lebih penting daripada ilusi atomisitas.
Menjalankan governance melalui NitroNet
Tentukan frekuensi perbandingan, atribut yang diperiksa, toleransi, dan waktu penyelesaian exception. Jangan otomatis menyalin nilai untuk “memperbaiki” semua perbedaan; sebagian variance menunjukkan proses yang belum selesai atau konflik authority. Laporan rekonsiliasi harus menyertakan provenance, versi, serta tindakan terakhir agar reviewer dapat memilih perbaikan tanpa membuka data pribadi lebih luas dari kebutuhan.
NitroNet dapat memvisualisasikan kontrak, mapping per field, lookup, kondisi, upsert, jalur error, dan respons. Agent menjaga credential dekat environment CRM atau billing yang privat. Workflow dapat membuat aturan terlihat saat review, tetapi tim tetap harus menetapkan source of truth, privacy, consent, dan kewenangan bisnis.
Mulailah dari alur satu arah dengan matriks ownership kecil, uji duplicate/out-of-order serta perubahan schema di Sandbox, kemudian tambahkan arah balik hanya bila diperlukan. Lanjutkan ke workflow order-to-fulfillment dan cost of change pada field untuk memperluas pola tanpa kehilangan boundary.