Menggunakan banyak kurir memberi bisnis lebih banyak pilihan harga, coverage, dan layanan. Namun, kompleksitasnya muncul setelah paket mulai dikirim.
Tim customer service harus membuka website JNE untuk satu pesanan, J&T untuk pesanan lain, kemudian SiCepat, AnterAja, Grab, atau kurir lainnya untuk order berikutnya. Ketika pelanggan bertanya “paket saya di mana?”, waktu CS justru habis untuk mencari informasi sebelum dapat menjawab.
Solusinya adalah centralized shipment tracking, yaitu mengumpulkan status pengiriman dari banyak kurir dalam satu dashboard atau sistem internal.
Biteship mengintegrasikan 30 lebih kurir melalui satu platform. Dashboard pengirimannya dapat digunakan untuk mengelola pengiriman, mengecek resi, dan memantau tracking tanpa login ke portal kurir satu per satu. Untuk bisnis yang memiliki sistem sendiri, Biteship juga menyediakan Tracking API dan webhook untuk mengirim update status pengiriman secara programmatic.
Key Takeaways
- Tracking terpusat mengurangi perpindahan antar-dashboard kurir, sehingga tim CS dan operasional dapat mencari status pengiriman dari satu sumber.
- Dashboard cocok untuk proses operasional tanpa development, sedangkan API dan webhook lebih cocok ketika tracking perlu terhubung dengan OMS, CRM, aplikasi, atau customer notification.
- Data tracking bukan hanya untuk menjawab pelanggan. Jika disimpan dengan baik, data tersebut dapat digunakan untuk mengidentifikasi shipment yang terlambat dan mengevaluasi performa kurir berdasarkan rute atau jenis layanan.
Kenapa Tracking Banyak Kurir Secara Manual Menjadi Masalah?
Misalnya bisnis mengirim 1.000 paket per bulan menggunakan lima ekspedisi.
Ketika terdapat 30 pelanggan yang menanyakan status paket dalam sehari, CS harus:
- Mencari order pelanggan.
- Menemukan kurir yang digunakan.
- Menyalin nomor resi.
- Membuka website kurir.
- Memasukkan nomor resi.
- Membaca histori perjalanan.
- Kembali ke customer service tool.
- Menjelaskan status kepada pelanggan.
Setiap kurir juga memiliki interface dan istilah tracking yang berbeda.
Website resmi JNE dan J&T, misalnya, menyediakan halaman tracking masing-masing. Artinya, tanpa sistem terpusat, bisnis memang perlu berpindah antar-platform ketika menggunakan beberapa ekspedisi.
Masalah ini semakin besar ketika bisnis menggunakan marketplace, webstore, WhatsApp order, dan aplikasi sendiri sekaligus.
Solusi: Centralized Multi-Courier Tracking
Centralized tracking menggabungkan status pengiriman dari beberapa kurir dalam satu interface.
Alih-alih:
JNE Dashboard → J&T Website → SiCepat Website → Grab → Kurir lainnya
tim menggunakan:
Satu dashboard → seluruh shipment
Biteship mempublikasikan dashboard pengiriman yang menghubungkan lebih dari 30 kurir dalam satu platform. Melalui dashboard tersebut, bisnis dapat menangani cek ongkir, pembuatan pengiriman, tracking, serta retur tanpa menggunakan tools terpisah.
Untuk kebutuhan tracking saja, Biteship juga memiliki halaman Cek Resi Semua Ekspedisi yang mendukung berbagai kurir. Halaman produk Biteship menyebut pelacakan bulk dapat dilakukan hingga 50 resi dalam satu waktu.
Pendekatan ini cocok untuk tim yang belum membutuhkan integrasi teknis.
Dashboard vs API Tracking: Mana yang Dibutuhkan?
Keduanya menyelesaikan masalah yang sama dengan tingkat otomatisasi berbeda.
| Kebutuhan | Dashboard | API + Webhook |
| Melihat status beberapa kurir | Ya | Ya |
| Cocok untuk tim non-teknis | Ya | Membutuhkan developer |
| Integrasi dengan sistem internal | Terbatas pada integrasi yang tersedia | Tinggi |
| Update customer otomatis | Bergantung workflow | Dapat dibangun otomatis |
| Custom alert shipment | Terbatas | Dapat dibuat berdasarkan business rule |
| Reporting internal khusus | Menggunakan dashboard/report tersedia | Dapat disimpan ke data warehouse sendiri |
| Cocok untuk | Tim CS dan operations | Platform, enterprise, SaaS, webstore custom |
Jika bisnis hanya ingin mengurangi kebiasaan membuka portal kurir, dashboard sudah cukup.
Jika tracking perlu masuk ke CRM, aplikasi, WhatsApp automation, ERP, atau customer portal, API lebih relevan.
Bagaimana Tracking API Bekerja?
Biteship menyediakan endpoint:
GET /v1/trackings/:id
Endpoint tersebut mengembalikan status dan histori pengiriman. Dokumentasi Biteship juga menstandardisasi status seperti:
- confirmed
- allocated
- pickingUp
- picked
- inTransit
- droppingOff
- delivered
- returnInTransit
- returned
- cancelled
Standardisasi membuat aplikasi tidak perlu menggunakan istilah berbeda untuk setiap ekspedisi.
Namun, ada batasan teknis yang penting: Tracking API tersebut didokumentasikan untuk order yang dibuat melalui Biteship Order API. Biteship menghasilkan tracking_id ketika order dibuat melalui API.
Jika bisnis memiliki resi dari workflow eksternal dan ingin memasukkannya ke sistem tracking sendiri, konfirmasikan dukungan workflow tersebut dengan provider sebelum implementasi.
Gunakan Webhook agar Tidak Perlu Polling Terus-Menerus
Sistem dapat melakukan polling:
GET tracking
GET tracking
GET tracking
GET tracking
Tetapi ketika ribuan shipment aktif, cara tersebut meningkatkan jumlah request yang harus dikelola.
Alternatifnya adalah webhook.
Alurnya:
Kurir memperbarui shipment
↓
Biteship menerima perubahan
↓
Webhook order.status dikirim
↓
Sistem bisnis memperbarui shipment
↓
CS / pelanggan mendapatkan status terbaru
Biteship menyediakan webhook untuk shipment status update sehingga sistem dapat bereaksi ketika status berubah. Dokumentasi Biteship juga menyebut penggunaan webhook membantu menjaga informasi tracking tetap terbaru tanpa terus melakukan pengecekan manual.
Webhook tersebut kemudian dapat memicu:
- Update CRM
- WhatsApp notification
- Push notification
- Ticket customer service
- Exception alert
- Data warehouse event
Dengan demikian, tracking menjadi bagian dari workflow operasional, bukan sekadar halaman untuk mengecek resi.
Bagaimana Tim CS Menggunakan Tracking Terpusat?
Bayangkan pelanggan menghubungi CS:
“Paket saya belum sampai. Bisa dicek?”
Dengan proses manual:
Cari order → cari kurir → buka website kurir → paste resi → cek → kembali ke chat
Dengan dashboard terpusat:
Cari order/resi → lihat shipment → jawab pelanggan
Jika aplikasi customer service terintegrasi langsung dengan API, prosesnya bisa lebih singkat:
Buka customer profile → tracking sudah tampil
Biteship sendiri memosisikan dashboard pengiriman sebagai satu tempat untuk tracking multi-kurir dan menyatakan bahwa kebutuhan memantau status melalui banyak dashboard membuat proses operasional kurang efisien.
Gunakan Tracking untuk Mendeteksi Pengiriman Bermasalah
Nilai tracking terpusat lebih besar jika tim tidak hanya menggunakannya ketika pelanggan menghubungi CS.
Buat aturan seperti:
Shipment terlalu lama di picked
Jika paket sudah diambil tetapi tidak bergerak menuju transit dalam periode internal tertentu, masukkan ke monitoring list.
Shipment terlalu lama di inTransit
Bandingkan dengan ETA dan service level. Jika melewati batas yang ditentukan bisnis, buat tiket untuk investigasi.
Status onHold
Prioritaskan untuk CS karena kemungkinan terdapat kendala alamat, penerima, atau proses kurir.
returnInTransit
Hubungkan dengan tim retur agar bisnis mengetahui barang sedang kembali ke origin.
Untuk pengiriman Indonesia Timur, monitoring seperti ini menjadi lebih penting karena jarak, konektivitas transportasi, kondisi cuaca, dan peak season dapat memengaruhi perjalanan. Baca Penyebab Keterlambatan Pengiriman Indonesia Timur untuk memahami faktor yang perlu diperhatikan pada rute tersebut.
Perlu diperhatikan, contoh alert di atas merupakan business rule yang dapat dibangun oleh bisnis, bukan klaim bahwa dashboard Biteship otomatis memberikan seluruh anomaly alert tersebut.
Gunakan Data Tracking untuk Mengevaluasi Kurir
Setelah status pengiriman terkumpul di satu sistem, data dapat digunakan untuk analisis operasional.
Contohnya, kelompokkan shipment berdasarkan:
- Kurir
- Service type
- Origin
- Destination
- Kota atau area
- Tanggal pengiriman
- Delivered date
- Return
- Delivery exception
Kemudian hitung:
On-time delivery rate = shipment sesuai SLA ÷ total shipment × 100%
Average transit time = total waktu transit ÷ shipment delivered
Exception rate = shipment bermasalah ÷ total shipment × 100%
Jangan langsung menyimpulkan bahwa satu kurir “terbaik” secara nasional.
Kurir A dapat tampil baik pada Jakarta ke Surabaya tetapi kurang konsisten pada rute lain. Karena itu, analisis sebaiknya dilakukan per rute dan service type.
Biteship mempublikasikan fitur Analitik & Laporan sebagai bagian dari ekosistem dashboard pengiriman. Untuk analisis rute atau KPI khusus yang tidak tersedia sebagai report standar, bisnis dapat menyimpan data API pada database atau BI tools sendiri.
Contoh Workflow Harian Tim Operations
Pagi
Filter seluruh shipment aktif dan lihat pesanan yang belum bergerak setelah pickup.
Prioritaskan:
- onHold
- Pickup gagal
- Shipment melewati ETA
- Shipment tanpa update
Siang
CS menggunakan dashboard yang sama untuk menjawab pertanyaan pelanggan.
Jika shipment normal, cukup berikan status dan tracking page. Jika ditemukan exception, buat tiket eskalasi.
Sore
Operations mengecek shipment yang seharusnya mencapai status tertentu sebelum akhir hari.
Untuk bisnis yang menggunakan API, pengecekan ini dapat diotomatisasi menggunakan status event dan rules.
Mingguan
Buat laporan:
| Metrik | Tujuan |
| Total shipment | Memantau volume |
| Delivered | Completion |
| Average transit time | Kecepatan |
| On-time rate | Kepatuhan SLA |
| Return | Masalah delivery |
| Exception rate | Stabilitas |
| Shipment tanpa update | Risiko operasional |
Data tersebut kemudian menjadi dasar diskusi dengan courier provider atau aggregator.
Jangan Lupa Berikan Tracking kepada Pelanggan
Tracking terpusat tidak hanya membantu tim internal.
Biteship menyediakan branded tracking page sehingga pelanggan dapat mengecek status paket tanpa membuka website kurir satu per satu. Halaman produk Shipping Biteship menyebut tracking page dapat disesuaikan dengan branding bisnis.
Alurnya menjadi:
Customer checkout → shipment dibuat → resi tersedia → tracking page → customer memantau sendiri
Semakin banyak informasi yang tersedia secara self-service, semakin sedikit pertanyaan dasar yang harus dijawab CS.
Untuk bisnis yang ingin lebih proaktif, webhook status juga dapat dihubungkan dengan WhatsApp Business Platform agar pelanggan menerima update tertentu tanpa harus membuka tracking page.
Biteship untuk Tracking Multi-Kurir
Biteship menyediakan beberapa tingkat penggunaan:
Cek Resi
Untuk pengecekan manual lintas ekspedisi.
Dashboard Pengiriman
Untuk tim operations dan CS yang ingin mengelola pengiriman, tracking, cek ongkir, serta retur dalam satu tempat.
Shipping API
Untuk perusahaan yang ingin memasukkan shipment dan tracking ke dalam sistem internal.
Webhook
Untuk automation berbasis perubahan status.
Platform Biteship saat ini terhubung dengan lebih dari 30 kurir. Dashboard pengiriman juga dapat diakses tanpa tim developer, sedangkan REST API tersedia untuk bisnis yang membutuhkan workflow khusus.
Dokumentasi teknis Tracking API dapat dilihat pada Biteship Trackings API.
Kesimpulan
Menggunakan banyak kurir tidak seharusnya membuat tracking ikut tersebar.
Tim CS dan operations membutuhkan satu sumber informasi untuk melihat status shipment, menemukan paket bermasalah, dan menjawab pertanyaan pelanggan tanpa membuka portal ekspedisi satu per satu.
Untuk operasional sederhana, dashboard multi-kurir dapat mengurangi pekerjaan manual. Jika volume dan kompleksitas meningkat, API dan webhook memungkinkan tracking masuk langsung ke CRM, OMS, aplikasi, notifikasi pelanggan, serta sistem analitik internal.
Biteship menyediakan dashboard pengiriman, Tracking API, webhook, dan tracking page untuk membantu bisnis mengelola shipment dari 30 lebih kurir dalam satu ekosistem.
Anda dapat mulai menggunakan Dashboard Pengiriman Biteship atau melihat Dokumentasi Trackings API untuk menentukan pendekatan yang paling sesuai dengan workflow bisnis.
