Retur: di sinilah kerugian nyata fulfillment sebenarnya bermula

Ketika seller membandingkan penyedia fulfillment, indikator yang paling sering dilihat adalah pengiriman keluar: akurasi outbound, cut-off, dan tarif. Namun di lapangan operasional, tempat kerugian nyata benar-benar menumpuk ada di lain sisi. Yaitu retur.

Invoice retur yang masuk setiap hari dari kurir dirapikan secara manual lalu ada yang terlewat; barang yang sudah diinspeksi tidak diketahui disimpan di mana sehingga tidak cocok dengan stok; shipper yang ingin tahu status retur harus menanyakannya satu per satu ke penyedia fulfillment — sebagian besar 3PL berhenti di sini.

RUNIC mengembangkan dan mengoperasikan sendiri sistem manajemen retur untuk menyelesaikan masalah ini. Ini bukan solusi pihak ketiga, melainkan platform khusus shipper yang dibangun bersama oleh tim operasional dan tim pengembangan internal RUNIC, dan disediakan gratis untuk shipper yang bermitra dengan RUNIC — termasuk penyesuaian kustom, tanpa biaya.

1. Invoice retur CJ, dikumpulkan otomatis 100%

Semua invoice retur yang masuk melalui kurir tercatat otomatis ke dalam sistem. Operator tidak perlu memasukkan invoice secara manual setiap hari.

Mengapa ini penting: input manual menimbulkan kelalaian. Satu retur yang terlewat menjadi "barang yang stoknya ada tapi tidak bisa ditemukan" dan berujung pada insiden pengiriman. RUNIC mengintegrasikan data logistik eksternal dengan sistem sehingga invoice tercatat otomatis saat masuk, dan invoice yang terkumpul otomatis dilindungi terpisah agar tidak bisa tertimpa akibat kesalahan manusia.

2. Pelacakan invoice retur real-time — pembeda yang jarang ada di industri

Sistem retur RUNIC memperbarui status secara otomatis bahkan per nomor invoice retur.

Sebagian besar penyedia fulfillment hanya melacak invoice outbound, dan invoice retur tidak ditangani secara terpisah di sistem. Umumnya, box retur baru diidentifikasi secara manual setelah tiba di pusat, atau shipper harus menanyakan statusnya satu per satu ke penyedia fulfillment. 99% penyedia di pasar berhenti di sini.

RUNIC berbeda.

• Dari permintaan retur → penjemputan kurir → pengangkutan → penerimaan di RUNIC → inspeksi → penerimaan ulang/pemusnahan, seluruh jalur dilacak otomatis
• Ketika shipper mencari dengan nomor invoice asal maupun nomor invoice retur, ia bisa melihat informasi pelacakan bertahap setara dengan invoice outbound — cukup tahu invoice asal saja, sistem secara otomatis turut melacak dan menampilkan invoice retur yang tercocokkan.
• Perubahan status real-time diperbarui otomatis oleh sistem, sehingga shipper dapat melihat status terkini tanpa perlu me-refresh.

Manfaat dalam penanganan CS: lebih dari sekadar cek status, ini bisa dimanfaatkan sebagai aset operasional.

• Konsumen bertanya "apakah retur saya sudah terkirim?" → shipper mencari invoice retur di sistem → langsung menjawab apakah sedang dijemput, sedang diangkut, atau sudah tiba dan sedang diinspeksi
• Mencatat status produk dan riwayat penanganan CS per invoice sehingga saat invoice yang sama dicari lagi nanti, konteks penanganan sebelumnya langsung terlihat — walau kasus yang sama ditanyakan ulang, tidak perlu memeriksa dari awal.
• Memungkinkan pengelolaan terpisah per alasan retur. Misalnya, dengan mengumpulkan hanya retur karena perubahan pikiran lalu mencabangkan alurnya ke penjualan ulang setelah inspeksi barang layak jual, penanganan grade-B, atau pengiriman ulang, tingkat pemusnahan bisa ditekan dan tingkat pemulihan stok bisa dinaikkan.
• Shipper bisa mengoperasikannya sendiri tanpa bertanya ke penyedia fulfillment, sehingga kecepatan penanganan dan otonomi operasional sama-sama meningkat.

3. Pencocokan pindai invoice asal — diakui sebagai penerimaan hanya saat barang benar-benar tiba

Retur yang sudah terdaftar di sistem belum berarti penerimaan selesai. RUNIC menempatkan tahap verifikasi pencocokan tersendiri pada saat barang benar-benar tiba di pusat.

• Saat box retur tiba, petugas memindai invoice asal (invoice outbound) yang menempel pada barang.
• Sistem mencocokkan otomatis nomor invoice asal itu dengan data invoice retur yang terdaftar.
• Hanya jika cocok, barang didaftarkan sebagai penerimaan nyata dan tercermin ke stok.

Mengapa ini penting:

• Saat retur yang keliru (barang seller lain, invoice berbeda, label hilang, dll.) tercampur masuk, sistem langsung memblokirnya.
• Mencegah insiden barang tidak diterima berupa "invoice retur terdaftar tapi barangnya tidak masuk" — masalah yang sering terjadi pada sistem yang hanya mengandalkan inspeksi manual.
• Pencocokan dua arah invoice outbound ↔ invoice retur tercatat, sehingga bisa dilacak bila terjadi sengketa di kemudian hari.

Fulfillment yang hanya mengandalkan inspeksi manual tidak memiliki tahap ini, sehingga kerap memproses retur keliru langsung sebagai penerimaan. Di RUNIC, penerimaan baru diakui setelah sistem memverifikasinya secara otomatis.

4. Pelacakan lokasi otomatis per barang retur — langsung tahu ada di mana

Lebih penting daripada fakta bahwa retur sudah diterima adalah "barang itu sekarang ada di mana". Sistem fulfillment umum hanya memproses sampai pendaftaran penerimaan, sedangkan lokasi penyimpanan bergantung pada ingatan atau catatan petugas. Seiring waktu muncul "barangnya ada tapi tidak tahu di mana" dan stok jadi tidak cocok.

Sistem retur RUNIC mencatat lokasi penyimpanan otomatis bersamaan dengan verifikasi penerimaan.

• Barang yang sudah selesai pencocokan pindai invoice asal, ketika tim inspeksi memindai posisi penyimpanan (rak, zona, nomor box), akan dipetakan otomatis ke sistem.
• Ketika shipper atau operator mencari dengan nomor invoice, nama produk, atau SKU, posisi penyimpanan saat ini langsung ditampilkan.
• Meski disimpan di zona berbeda menurut statusnya — layak jual, grade-B, menunggu pemusnahan — sistem melacak semuanya.

Bagaimana digunakan di lapangan:

• Saat perlu inspeksi ulang produk tertentu karena klaim mitra → cari lokasi di sistem → pencarian yang tadinya puluhan menit dipangkas jadi puluhan detik
• Saat menjadwalkan inspeksi pemulihan barang layak jual → optimalkan alur kerja berdasarkan lokasi
• Saat stock opname → mencocokkan posisi di sistem dengan posisi stok fisik → langsung mengidentifikasi ketidaksesuaian
• Saat pemusnahan → memproses sekaligus barang yang terkumpul di zona tunggu pemusnahan

Bila "retur sudah masuk tapi tidak tahu ada di mana" adalah kenyataan fulfillment pada umumnya, di RUNIC penerimaan retur dan pelacakan lokasi dijalankan sebagai satu alur.

5. Integrasi berbagai jalur input — cukup sudah menulis-ulang secara manual

Kami menyediakan 5 jalur pendaftaran retur yang disesuaikan dengan lapangan operasional.

• Pengumpulan otomatis — invoice terdaftar otomatis lewat integrasi data logistik eksternal
• Pengalihan penerimaan retur CS dari WMS — daftar "sedang penerimaan retur" yang didaftarkan tim CS di WMS RUNIC dipilih per item lalu dialihkan dan didaftarkan apa adanya ke sistem retur. Karena CS dan tim retur bekerja di atas data yang sama, tidak perlu input dua kali.
• Pendaftaran pencarian terpadu — menemukan order asli lewat nama penerima, nomor order, atau nomor invoice, lalu ditampilkan terpisah per line item (per produk) → seleksi ganda untuk pendaftaran sekaligus
• Unggah Excel — pendaftaran massal
• Pindai barcode — daftar langsung di lokasi penerimaan

Walau satu order berisi beberapa produk, kartu ditampilkan terpisah per produk, sehingga meski dalam order yang sama, memungkinkan manajemen presisi seperti produk A diretur sementara produk B dibiarkan. Produk yang sudah terdaftar otomatis diberi tanda "Terdaftar" untuk mencegah pendaftaran ganda.

6. Pengecekan status retur real-time — penanganan CS jadi lebih cepat

Selain pelacakan invoice retur, tahap pemrosesan setelah penerimaan juga seluruhnya ditampilkan ke shipper secara real-time.

Bagaimana digunakan di lapangan CS:

• Konsumen bertanya "saya kirim retur kemarin, sudah diproses belum?" → buka sistem sekali, cari invoice → langsung terlihat tahap sedang dijemput, diterima, selesai inspeksi, hingga penerimaan ulang → bisa langsung menjawab
• Klaim retur sudah tiba tapi refund lambat → cek real-time apakah di tahap inspeksi atau tahap penerimaan ulang → bisa menginformasikan hingga perkiraan tanggal pemrosesan yang akurat
• Mitra B2B minta konfirmasi jumlah retur → karena status ditampilkan terpisah per line item, memungkinkan penanganan rinci seperti produk A selesai diterima ulang, produk B diproses pemusnahan

Penanganan CS yang dulu berbunyi "akan saya cek dan hubungi kembali", dengan sistem retur RUNIC jawabannya keluar saat itu juga. Seiring berkurangnya waktu penanganan, kepuasan pelanggan dan tingkat pembelian ulang pun naik.

7. Data retur menjadi statistik — "mengapa retur terjadi" jadi terlihat

Sistem retur RUNIC bukan sekadar alat pencatat invoice. Data retur yang terakumulasi diubah otomatis menjadi statistik untuk memberi wawasan yang bisa dipakai shipper memperbaiki operasi berikutnya.

Contoh statistik yang ditampilkan sistem:

• Tingkat retur per produk/SKU — produk mana yang paling banyak mengalami retur
• Distribusi alasan retur — alasan apa yang paling banyak: perubahan pikiran, cacat, salah kirim, ukuran meleset, dll.
• Tren retur per periode — apakah retur menumpuk tepat setelah musim, promosi, atau event tertentu
• Rasio penerimaan ulang, pemusnahan, grade-B — berapa persen retur yang terkumpul bisa dijual lagi
• Tingkat retur per mitra/channel — channel mana yang lebih banyak menghasilkan retur

Poin perbaikan yang didapat shipper:

• Tingkat retur SKU tertentu abnormal tinggi → perkuat deskripsi, foto, dan informasi ukuran di halaman detail
• Banyak retur karena alasan ukuran → perbarui panduan ukuran atau tingkatkan akurasi opsi
• Retur menumpuk di channel tertentu → periksa konten tampilan channel dan penanganan CS
• Terlihat pola tingkat retur per musim → sesuaikan jumlah pemesanan dan pengelolaan stok musim berikutnya
• Ditemukan kategori dengan tingkat pemusnahan tinggi → tinjau ulang cara pengemasan dan pengangkutan

Retur bukan sekadar beban operasional, melainkan data yang bisa memperbaiki perencanaan produk dan strategi penjualan. Sistem RUNIC mengompilasi otomatis data itu agar shipper bisa mengaksesnya langsung, sehingga tak perlu meminta secara khusus ke penyedia fulfillment.

8. Sistem memblokir "perubahan nilai yang tidak diniatkan"

Ada insiden yang lazim di industri — saat menyimpan form, item yang sama sekali tidak disentuh pengguna diam-diam berubah menjadi opsi pertama sehingga data rusak. Sistem RUNIC melacak apakah suatu item benar-benar disentuh pengguna, sehingga item yang tidak disentuh tetap mempertahankan nilai lamanya.

Artinya: meski operator sedang bekerja di sel lain lalu tidak sengaja hanya menekan tombol simpan, item lain tidak rusak. Integritas data terjamin di tingkat sistem.

9. Sekali penerimaan, sekali label

Barang yang selesai diinspeksi, dengan satu tombol penerimaan, waktu penerimaannya tercatat otomatis. Barang yang butuh label, dengan satu tombol cetak label, akan mencetak barcode, nomor manajemen, dan nama produk. Output PDF yang sudah teruji kompatibel dengan printer label langsung dicetak tanpa konversi terpisah.

10. Data besar pun aman

Saat mengunduh puluhan ribu data retur ke Excel, sistem membuat file di latar belakang sambil menampilkan progres secara real-time lewat modal (total jumlah / jumlah selesai / persentase / waktu berlalu / sisa waktu). Anda bisa terus mengerjakan tugas lain selama menunggu unduhan.

11. Shipper melihat langsung, hanya datanya sendiri

Karena hak akses dipisah, shipper hanya dapat melihat data perusahaannya sendiri, tim inspeksi hanya bisa mengubah waktu penerimaan, dan hanya admin yang melihat seluruh data operasional. Struktur multi-tenant membuat data antar-shipper tidak tercampur.

Yang didapat shipper

• Menggunakan semua fitur di atas secara gratis — tanpa biaya lisensi solusi maupun biaya per akun
• Bahkan penyesuaian kustom untuk shipper pun gratis dan diterapkan dengan cepat
• Mengecek langsung status retur tanpa bertanya ke penyedia fulfillment
• Melacak real-time seluruh jalur penjemputan → pengangkutan → penerimaan → inspeksi → penerimaan ulang dengan nomor invoice retur
• Langsung mencari lokasi penyimpanan (rak, zona, box) barang retur yang diterima lewat invoice/SKU
• Menjawab seketika pertanyaan CS dari konsumen dan mitra — waktu penanganan lebih singkat, pembelian ulang naik
• Menggali poin perbaikan per produk, channel, dan musim dari data retur yang terakumulasi
• Mencegah dini ketidaksesuaian stok akibat kesalahan jumlah atau invoice
• Meningkatkan kecepatan operasi dengan memisahkan sekaligus penanganan CS dan penerimaan retur
• Mengakses langsung data tingkat retur, tingkat penerimaan ulang, dan tingkat pemusnahan per SKU

Disediakan gratis untuk shipper — termasuk penyesuaian kustom tanpa biaya

Sistem manajemen retur RUNIC disediakan gratis untuk shipper yang bermitra dengan RUNIC. Tidak ada biaya lisensi solusi terpisah maupun biaya per akun. Bagi shipper yang mempercayakan operasi returnya kepada RUNIC, semua fitur yang dijelaskan di atas — pengumpulan invoice otomatis, pelacakan invoice retur, pencocokan invoice asal, pelacakan lokasi, hingga statistik — dapat digunakan apa adanya tanpa biaya tambahan.

Yang lebih penting adalah penyesuaian kustom pun gratis. Pada solusi pihak ketiga, mengubah satu layar saja harus mengambil penawaran terpisah dari vendor dan membayar biaya pengembangan. RUNIC berbeda.

• Pengembangan kustom juga gratis — permintaan shipper seperti integrasi channel tertentu, format label khusus mitra, sistem klasifikasi alasan, alur inspeksi khusus, dan penambahan item statistik diterapkan tanpa biaya terpisah
• Penerapan cepat — karena tim pengembangan internal yang menjalankan langsung, dari permintaan → peninjauan → pengembangan → penerapan berlangsung dalam satu tim. Tanpa tahap permintaan eksternal, penawaran, atau kontrak, sehingga tidak perlu menunggu berminggu-minggu hingga berbulan-bulan.
• Karena tim operasional dan tim pengembangan berada dalam satu perusahaan, umpan balik lapangan langsung tercermin ke sistem
• Dengan alur yang sama, WMS dan TMS milik sendiri juga dikembangkan dan dioperasikan di internal RUNIC — retur dan alat operasional lain terhubung sebagai satu alur

Ketika shipper bertanya "bisakah diubah menjadi seperti ini?", RUNIC bisa menjawab "akan kami tinjau, kembangkan, lalu terapkan — tanpa biaya". Jawaban yang sulit diberikan oleh fulfillment yang memakai solusi pihak ketiga.

Hal ini mungkin karena perusahaan yang mengoperasikannya sendiri yang membuatnya. RUNIC memahami kenyataan lapangan bahwa tiap shipper punya cara operasi berbeda, format label mitra berbeda, dan standar inspeksi penerimaan berbeda. Karena itu sistem tidak dibeli dari luar melainkan dibangun sendiri, dan sistem itu dipakai bersama shipper secara gratis.

Situs resmi www.runic.kr · Inspeksi Outbound Pengiriman B2B · Checklist SLA · Panduan Fulfillment SmartStore →