Integrasi pengiriman dengan CRM: data apa yang dipertukarkan dan bagaimana menyiapkannya

Apa yang rusak ketika CRM dan pengiriman berjalan terpisah

CRM mengurus hubungan dengan pelanggan: di sana ada deal, kontak, kesepakatan soal tenggat dan pembayaran. Sistem manajemen pengiriman mengurus eksekusi: siapa yang berangkat, dengan urutan apa, dan dengan bukti apa pekerjaan dinyatakan selesai. Selama dua lingkaran ini belum terhubung, di antaranya selalu ada orang yang memindahkan data secara manual — dan ongkos pemindahan itu jauh lebih besar daripada sekadar waktu yang terbuang.

Akibat khas dari keterputusan ini biasanya seperti ini:

• Input ganda dan salah ketik. Alamat yang diketik ulang adalah alamat yang berpeluang salah. Petugas berangkat ke tempat yang keliru, dan masalahnya baru ketahuan di lapangan.
• Status yang selalu telat. Sales tidak tahu apa yang terjadi dengan order, lalu menjawab pelanggan «sebentar saya cek dulu» alih-alih memberi jawaban pasti. Setiap pengecekan seperti itu berarti satu telepon lagi ke dispatcher.
• Order yang hilang. Deal sudah pindah ke tahap «diserahkan ke pengiriman», tetapi tidak pernah sampai ke dispatcher: tidak ada yang menyadarinya sampai pelanggan menelepon.
• Laporan yang tidak cocok. Di CRM jumlah kirimannya sekian, di sistem operasional sekian lagi, dan hanya karyawan dengan ingatan detail yang bisa menjelaskan selisihnya.

Integrasi menghapus lapisan manual itu: order muncul di layar dispatcher tepat saat deal mencapai tahap yang ditentukan, dan hasil eksekusinya kembali ke kartu pelanggan tanpa perlu diceritakan ulang. Sisanya — notifikasi, analitik, kenyamanan antarmuka — hanyalah lapisan di atas pertukaran dasar tersebut. Karena itu, rancang integrasi dengan bertanya «fakta apa yang harus mengalir dan ke arah mana», bukan «tombol mana yang harus ditekan».

Data apa yang mengalir antara CRM dan sistem pengiriman

Pertukaran hampir selalu dua arah, dan paling mudah dijabarkan lewat dua daftar pendek — apa yang keluar dari CRM dan apa yang kembali. Dari CRM ke sistem pengiriman biasanya dikirim:

• order atau permintaan kerja: nomor, jenis pekerjaan, isi kiriman, catatan dari sales;
• alamat tujuan beserta detail akses — blok, lantai, kartu masuk, siapa yang ditelepon di lokasi;
• kontak penerima dan jendela waktu yang sudah disepakati;
• nominal dan metode pembayaran, jika petugas menerima uang di tempat;
• penanda urgensi atau prioritas — agar dispatcher tahu order ini tidak boleh digeser ke besok.

Sebaliknya, dari sistem pengiriman ke CRM kembali fakta-fakta eksekusi:

• petugas yang ditugaskan dan perkiraan waktu tiba;
• status: diterima, berangkat, tiba di lokasi, selesai, gagal;
• alasan kegagalan dari daftar tertutup — pelanggan menolak, tidak bisa dihubungi, alamat tidak ditemukan, dijadwalkan ulang atas permintaan pelanggan;
• bukti: foto, tanda tangan penerima, waktu dan lokasi saat penandaan;
• pembayaran yang diterima di tempat, kalau memang ditagih oleh petugas.

Yang juga perlu disepakati tersendiri adalah data induk pelanggan dan alamat. Kalau keduanya boleh dibuat dari dua sisi, duplikat akan muncul di bulan pertama: «PT Melati» dan «Melati, PT» menjadi dua catatan dengan riwayat berbeda, dan laporan per pelanggan terpaksa dirakit manual. Lebih sederhana menunjuk satu sistem sebagai pemilik data induk, dan yang lain sebagai pemakainya.

Satu trik praktis yang menghemat berminggu-minggu diskusi: sebelum pekerjaan dimulai, tulis semua field ke tabel empat kolom — nama di CRM, nama di sistem pengiriman, arah pertukaran, dan apa yang dilakukan kalau nilainya kosong. Dokumen satu halaman itulah spesifikasi teknis integrasi Anda.

Cara pertukaran: API, webhook, dan unggah berkas

Secara teknis, ada beberapa jalan untuk menyambungkan kedua sistem. Pilihannya bukan soal tren, melainkan soal seberapa cepat data dibutuhkan dan kemampuan apa yang tersedia di CRM Anda.

• Pertukaran lewat API. Kedua sistem saling memanggil secara langsung. Ini pilihan paling fleksibel: field apa pun bisa dikirim dan logikanya sepenuhnya terkendali. Imbalannya, perlu konfigurasi dan pemahaman metode mana yang dipanggil pada peristiwa mana.
• Webhook. CRM sendiri yang mengabarkan bahwa deal pindah ke tahap tertentu, dan sistem pengiriman mengabarkan perubahan status. Data ter-update nyaris seketika tanpa polling berulang, tetapi mekanisme percobaan ulang harus dipikirkan sejak awal: kalau penerima sedang tidak tersedia, peristiwa itu tidak boleh hilang begitu saja.
• Unggah berkas. Order dikirim per batch sesuai jadwal, misalnya dari spreadsheet. Ini cara tercepat untuk mulai: tidak perlu pengembangan, cocok bila daftar order sudah terkumpul pagi hari dan jarang berubah sepanjang hari.
• Konektor perantara. Sebuah layanan jembatan tersendiri menyelaraskan format, menyimpan pemetaan dan aturannya. Ini masuk akal bila sumbernya lebih dari satu: sebagian order datang dari CRM, sebagian dari sistem akuntansi, sebagian dari formulir di situs.

Tidak ada jawaban universal, tetapi ada patokan sederhana. Kalau pelanggan menunggu status di hari yang sama dan sales sering menjawab telepon «pesanan saya di mana», Anda butuh pertukaran berbasis peristiwa. Kalau arus order sudah terbentuk sehari sebelumnya dan stabil, unggah berkas sudah cukup — dan baru perlu dipersulit ketika muncul kebutuhan konkret yang tak lagi bisa ditanganinya.

itlogist mendukung integrasi dengan AmoCRM, Bitrix24, 1C, dan Excel — order masuk ke antrean kerja dari sumber yang sudah biasa dipakai, tanpa pengetikan ulang. Apa yang terjadi setelahnya — pembagian order ke petugas, rute di peta secara real-time, aplikasi mobile petugas dengan laporan foto dan checklist, portal pelanggan berisi status — dirangkum di halaman Fitur itlogist.

Pemilik kebenaran, kunci pencocokan, dan penanganan galat

Sebagian besar masalah integrasi bukan bersifat teknis, melainkan soal kesepakatan. Berikut empat pertanyaan yang jawabannya menentukan apakah pertukaran bisa berjalan tanpa diawasi setiap hari.

• Kunci pencocokan. Berdasarkan field apa order di sistem pengiriman dicocokkan dengan deal di CRM — nomor deal, ID internal, atau nomor pesanan. Kuncinya harus tunggal, tidak berubah, dan dikirim ke dua arah. Mencocokkan lewat nomor telepon atau alamat pasti berantakan pada order berulang dari pelanggan yang sama.
• Pemilik kebenaran untuk tiap field. Siapa yang berkuasa atas alamat, siapa atas waktu kunjungan, siapa atas nominal. Kalau sales mengubah jendela waktu di CRM dan dispatcher mengubahnya di sistem pengiriman, yang menang bukan siapa yang menekan tombol paling akhir, melainkan siapa yang ditetapkan oleh aturan.
• Model status yang seragam. Tahapan funnel di CRM dan status eksekusi adalah dua hal berbeda. Perlu tabel pemetaan yang eksplisit: status operasional mana memindahkan deal ke tahap mana, dan transisi mana yang dilarang. Kalau tidak, deal akan mundur ke tahap sebelumnya setiap kali ada percobaan kunjungan ulang.
• Perilaku saat galat. Apa yang terjadi kalau alamatnya kosong, pelanggannya tidak ditemukan, atau penerimanya tidak merespons. Skenario yang sehat: order tidak hilang diam-diam, melainkan masuk ke antrean percobaan ulang atau ke daftar untuk ditangani manual — dan ada orang yang bertanggung jawab atas daftar itu.

Ada dua hal lagi yang biasanya baru diingat belakangan. Pertama, pengiriman ulang tidak boleh menciptakan duplikat: kalau satu peristiwa datang dua kali, percobaan kedua wajib memperbarui order yang sudah ada, bukan membuat yang baru. Kedua, soal hak akses: akun integrasi hanya boleh melihat dan mengubah apa yang diperlukan untuk pertukaran, dan aksesnya tidak boleh menempel pada satu karyawan tertentu yang suatu hari akan pergi membawa kata sandinya.

Urutan penerapan: dari satu skenario ke arus penuh

Integrasi sebaiknya tidak diluncurkan sekaligus untuk semua kasus. Urutan yang terbukti berjalan seperti berikut, dan biasanya selesai dalam beberapa iterasi pendek.

• Jabarkan satu skenario secara utuh. Ambil jenis order yang paling sering terjadi dan telusuri dari tahap di CRM sampai penandaan selesai. Kasus tidak standar — retur, penolakan sebagian, kunjungan ulang — tambahkan pada langkah kedua.
• Sepakati peta field. Tabel empat kolom tadi. Selama belum disetujui kedua pihak, terlalu dini untuk mulai mengonfigurasi.
• Bereskan kualitas data. Alamat yang sudah dinormalkan, nomor telepon yang aktif, catatan akses lokasi. Integrasi juga mempercepat perpindahan sampah: alamat yang buruk hanya akan lebih cepat sampai ke tangan petugas.
• Uji dengan arus percobaan. Sekitar sepuluh order ke dua arah, termasuk yang sengaja dibuat salah: tanpa alamat, duplikat, dan dibatalkan setelah penugasan.
• Hentikan pemindahan manual. Begitu pertukaran berjalan, cara lama harus dimatikan. Dua skema paralel selalu berakhir dengan data yang berbeda dan perdebatan mana yang benar.
• Sepakati dukungannya. Siapa yang memantau antrean galat, seberapa cepat harus merespons, dan apa yang dilakukan bila salah satu sistem sedang tidak tersedia.

Beberapa indikator sederhana, dicatat sebelum dan sesudah, cukup untuk menilai hasilnya: berapa lama jarak dari deal berpindah tahap sampai order muncul di layar dispatcher, berapa banyak order yang masih dibuat manual, dan seberapa sering sales menelepon dispatcher hanya untuk menanyakan status. Indikator terakhir biasanya berubah paling awal — dari situ terlihat bahwa informasi mulai mengalir lewat sistem, bukan lewat orang.

Ambang masuknya lebih rendah daripada yang umumnya dikira: peluncuran memakan waktu 7 hari, tanpa kontrak jangka panjang, dan platformnya dirancang untuk tim berisi 5 sampai 100 petugas lapangan. Artinya, sambungan dengan CRM bisa diuji pada arus order sungguhan dan dibandingkan dengan angka awal hanya dalam waktu sebulan.