Website Ekspedisi: Rancang Fitur Cek Resi dan Estimasi Ongkir

Fitur cek resi dan estimasi ongkir adalah dua alasan utama pelanggan membuka website ekspedisi. Keduanya terlihat sederhana: satu kotak isian nomor resi dan satu kalkulator tarif. Namun keduanya bergantung pada data operasional yang dapat dipercaya. Tampilan pelacakan yang rapi tidak membantu bila pembaruan kiriman terlambat atau statusnya sulit dimengerti pelanggan.

Artikel ini ditujukan untuk pemilik dan manajer perusahaan logistik atau ekspedisi yang ingin membangun atau memperbaiki website. Pembahasannya berurutan: sumber data, tampilan status, perlindungan data penerima, dasar perhitungan ongkir, lalu pengujian ketika integrasi gagal.

Singkatnya, tentukan dulu dari mana status dan tarif berasal, siapa yang memperbaruinya, dan apa yang tampil ketika data tidak tersedia. Setelah itu baru desain halamannya.

Mulai dari sumber data status kiriman

Petakan asal setiap status yang akan dilihat pelanggan. Umumnya ada tiga kemungkinan, dan banyak perusahaan memakai lebih dari satu:

• Sistem internal: aplikasi gudang atau operasional yang dipakai tim saat menerima, menyortir, dan memberangkatkan paket.
• Mitra pengiriman: kurir lain atau agregator yang menyediakan API pelacakan untuk rute yang tidak Anda layani sendiri.
• Input petugas: status yang diketik manual oleh admin cabang atau kurir di lapangan.

Tentukan siapa yang berhak memperbarui kejadian kiriman dan bagaimana koreksi dilakukan bila nomor resi atau status salah. Koreksi sebaiknya tidak menghapus riwayat lama, tetapi menambah catatan baru beserta nama petugas dan waktunya. Dengan begitu, tim bisa menelusuri asal kesalahan ketika pelanggan mengajukan keluhan. Prinsip ini dibahas lebih rinci di artikel audit trail untuk mencatat setiap perubahan data.

Bila memakai beberapa mitra, istilah status mereka hampir pasti berbeda. Buat daftar status standar milik perusahaan sendiri, lalu petakan status setiap mitra ke daftar itu. Sebagai gambaran, dokumentasi API agregator pengiriman Biteship mendefinisikan status baku seperti picked, inTransit, onHold, delivered, dan returned. Anda tidak harus memakai nama yang sama, tetapi prinsipnya serupa: pelanggan cukup melihat satu kosakata yang konsisten.

Jika data kiriman masih tersebar di grup WhatsApp dan spreadsheet, fitur cek resi akan sulit akurat. Pada kondisi ini, kebutuhan Anda mungkin bukan sekadar halaman web. Baca dulu perbandingan website dan sistem informasi untuk kebutuhan bisnis sebelum menyusun ruang lingkup proyek.

Tampilkan status cek resi yang membantu pelanggan

Pelanggan membuka halaman pelacakan karena ingin tahu dua hal: paketnya ada di mana dan kapan kira-kira tiba. Susun tampilan untuk menjawab pertanyaan itu.

• Arti setiap tahap dalam bahasa pelanggan. Contohnya, "Diterima di gudang Pekanbaru" lebih jelas daripada kode internal seperti "HUB-IN".
• Waktu pembaruan terakhir lengkap dengan zona waktu (WIB, WITA, atau WIT), karena rute antarpulau melewati zona yang berbeda.
• Langkah tindak lanjut bila status tertahan, misalnya alamat tidak lengkap atau penerima tidak di tempat, beserta kontak cabang yang menangani.

Hindari menyebut "real-time" bila pembaruan sebenarnya berkala. Ketika layanan mitra tidak merespons, tampilkan pesan yang jujur, misalnya "Data terbaru dari mitra belum dapat dimuat. Status terakhir yang kami terima: Dalam perjalanan, 14.20 WIB." Tambahkan saluran bantuan di bawahnya.

Rancang kolom input resi yang memaafkan kesalahan kecil

Banyak pencarian gagal karena hal sepele: spasi di awal atau akhir, huruf kecil, atau tanda hubung yang ikut tersalin dari chat. Rapikan input secara otomatis sebelum dicari. Bila resi memang tidak ditemukan, beri penjelasan yang membantu, misalnya resi baru aktif setelah paket diproses di gudang. Prinsip serupa ada di artikel merancang form input yang cepat diisi dan minim kesalahan.

Lindungi data penerima di halaman pelacakan

Nomor resi tertera di label paket, sering muncul di foto dan video unboxing, dan dibagikan lewat chat. Anggap resi bukan rahasia. Karena itu, nomor resi tidak seharusnya menjadi jalan untuk melihat alamat lengkap, nomor telepon, atau dokumen pengiriman.

Untuk pengguna umum, tampilkan seperlunya: kota asal dan tujuan, riwayat status, dan nama penerima yang disamarkan. Detail lengkap seperti alamat dan bukti serah terima sebaiknya hanya untuk pengirim atau penerima yang sudah login, atau setelah verifikasi tambahan.

Di sisi teknis, risiko ini dikenal dalam OWASP API Security Top 10 2023 sebagai Broken Object Level Authorization (API1:2023). Celah ini terjadi ketika API tidak memeriksa apakah peminta berhak mengakses objek tertentu, sehingga penyerang cukup mengganti ID di permintaan. OWASP menyarankan pemeriksaan otorisasi pada setiap fungsi yang mengambil data berdasarkan input pengguna. OWASP juga menyarankan ID acak yang sulit ditebak. Ingat, ID acak hanya menyulitkan tebakan dan tidak menggantikan pemeriksaan izin. Ini relevan bila nomor resi Anda berurutan.

Indonesia juga memiliki Undang-Undang Nomor 27 Tahun 2022 tentang Pelindungan Data Pribadi, yang ditetapkan 17 Oktober 2022. Undang-undang ini mengatur kewajiban pihak yang memproses data pribadi. Libatkan penasihat hukum perusahaan untuk memastikan kewajiban yang berlaku pada proses Anda.

Tentukan dasar perhitungan estimasi ongkir

Kalkulator ongkir hanya seakurat aturan tarif di belakangnya. Sebelum meminta pengembang membuat kalkulator, siapkan dasar perhitungannya:

• Wilayah asal dan tujuan serta cakupan layanan per rute.
• Berat, dimensi, dan aturan berat volumetrik yang digunakan.
• Jenis layanan (reguler, kilat, kargo) dan biaya tambahan yang berlaku, misalnya asuransi atau pengemasan kayu.
• Masa berlaku tarif serta siapa yang memperbarui data tarif.
• Perbedaan antara estimasi di website dan tagihan final.

Jelaskan berat volumetrik kepada pelanggan

Paket ringan tetapi besar memakan ruang angkut. Karena itu, banyak penyedia menghitung berat volumetrik. Penjelasan dari perusahaan pengiriman DPD menyebut rumus yang umum dipakai adalah panjang × lebar × tinggi (cm) dibagi 6.000. Hasilnya dibandingkan dengan berat aktual, dan tarif dihitung dari angka yang lebih besar. DPD juga menegaskan bahwa perhitungan bergantung pada masing-masing penyedia layanan. Jadi, pakai pembagi yang benar-benar berlaku di perusahaan Anda.

Contoh: kardus 40 × 30 × 30 cm memiliki volume 36.000 cm³. Dengan pembagi 6.000, berat volumetriknya 6 kg. Jika berat aktualnya 4 kg, tarif dihitung dari 6 kg. Tampilkan contoh seperti ini di dekat kalkulator agar pelanggan tidak kaget saat menerima tagihan.

Jika perhitungan membutuhkan survei atau negosiasi, misalnya kargo besar, pindahan, atau sewa armada, formulir permintaan penawaran lebih tepat daripada kalkulator yang memberi angka terlalu pasti. Jelaskan informasi yang perlu disiapkan calon pelanggan, seperti jenis barang, perkiraan volume, alamat jemput, dan tanggal yang diinginkan.

Uji kegagalan integrasi sebelum website ekspedisi diluncurkan

Fitur cek resi dan ongkir biasanya gagal di skenario yang jarang diuji. Minta pengembang menguji setidaknya hal berikut:

1. Resi tidak ditemukan, termasuk resi salah ketik dan resi yang belum diproses.
2. Status terlambat, yaitu paket bergerak tetapi status belum diperbarui berjam-jam.
3. API mitra tidak tersedia atau terlalu lama merespons. Halaman tetap harus terbuka dan menampilkan status terakhir yang tersimpan.
4. Batas permintaan terlampaui. Menurut MDN, kode HTTP 429 berarti klien mengirim terlalu banyak permintaan dalam rentang waktu tertentu. Server dapat menyertakan header Retry-After untuk memberi tahu berapa lama klien perlu menunggu.
5. Tarif belum mendukung tujuan tertentu. Tampilkan pesan dan arahkan ke formulir penawaran, bukan angka nol.

Simpan kredensial integrasi di server, jangan di kode yang berjalan di browser. Halaman cek resi publik juga perlu dibatasi, karena mudah dipanggil berulang-ulang oleh skrip. OWASP API4:2023 (Unrestricted Resource Consumption) menyarankan pembatasan laju permintaan sesuai kebutuhan bisnis. OWASP juga menyarankan batas belanja untuk semua integrasi pihak ketiga, atau peringatan tagihan bila batas belanja tidak tersedia. Ini penting bila mitra menagih per panggilan API. Menyimpan hasil pelacakan sementara selama beberapa menit juga membantu mengurangi panggilan yang tidak perlu.

Sediakan catatan masalah agar petugas dapat menindaklanjuti tanpa meminta pelanggan mengulang semua informasi. Pastikan pula perubahan status konsisten antara website dan aplikasi internal yang digunakan tim. Bila keduanya membaca sumber data berbeda, pelanggan dan petugas bisa melihat status yang tidak sama.

Pertanyaan yang sering diajukan

Apakah website ekspedisi kecil perlu membangun API cek resi sendiri?

Tidak selalu. Bila seluruh pengiriman dilayani armada sendiri, status bisa langsung dibaca dari sistem operasional internal. Bila sebagian besar rute memakai mitra, memanfaatkan API mitra atau agregator sering lebih praktis. Pastikan syarat penggunaan, batas permintaan, dan biayanya sudah diperiksa.

Kenapa estimasi ongkir di website bisa berbeda dengan tagihan akhir?

Penyebab umumnya adalah berat volumetrik, dimensi yang berbeda setelah paket diukur ulang, biaya tambahan seperti asuransi, atau tarif yang sudah berubah. Beri label "estimasi" dengan jelas dan tampilkan tanggal berlaku tarif.

Data apa yang aman ditampilkan di halaman cek resi publik?

Riwayat status, kota asal dan tujuan, waktu pembaruan, dan nama penerima yang disamarkan umumnya cukup. Alamat lengkap, nomor telepon, dan dokumen sebaiknya hanya untuk pengguna yang terverifikasi.

Bisakah fitur cek resi dan ongkir dibangun bertahap?

Bisa. Banyak perusahaan memulai dari cek resi untuk armada sendiri dan formulir permintaan penawaran. Integrasi mitra dan kalkulator tarif otomatis ditambahkan setelah data tarif dan status sudah rapi.

Referensi

• OWASP API Security Top 10 2023: API1 Broken Object Level Authorization
• OWASP API Security Top 10 2023: API4 Unrestricted Resource Consumption
• MDN Web Docs: 429 Too Many Requests
• DPD: What is volumetric weight?
• Dokumentasi API Biteship: Tracking Status
• JDIH BPK: UU Nomor 27 Tahun 2022 tentang Pelindungan Data Pribadi

Sebelum menjanjikan fitur cek resi atau estimasi ongkir kepada pelanggan, pastikan sumber data dan batas integrasinya jelas. Tim konsultan IT dan integrasi sistem Anaverse dapat membantu memetakan alur operasional, sistem yang sudah dipakai, dan kebutuhan website Anda. Kirim gambaran alur pengiriman dan contoh status kiriman ke Anaverse untuk mendiskusikan langkah awalnya.