Customer Portal Logistik: Menghentikan Pertanyaan yang Seharusnya Tidak Perlu Ditanyakan

Hitung berapa banyak pesan dan telepon yang masuk ke tim operasional Anda minggu lalu yang isinya menanyakan status. Di sebagian besar perusahaan logistik, angkanya mengejutkan, dan hampir seluruhnya menanyakan sesuatu yang sudah tercatat di suatu tempat dalam organisasi Anda.

Ini bukan masalah pelayanan. Ini masalah distribusi informasi. Data ada, tetapi berada di sisi yang salah dari dinding organisasi, sehingga setiap kali dibutuhkan harus ada manusia yang mengambilnya dan memindahkannya.

Dasar pertama: pertanyaan status adalah antrean yang tidak dikelola

Hukum Little, salah satu hasil paling kokoh dalam teori antrean, menyatakan hubungan sederhana yang berlaku pada sistem stabil mana pun: L = λ × W. Jumlah pekerjaan yang sedang menumpuk di dalam sistem (L) sama dengan laju kedatangan pekerjaan (λ) dikalikan waktu rata-rata pekerjaan itu berada di sistem (W).

Terapkan ke tim customer service Anda. Kalau 40 pertanyaan status masuk per hari dan masing-masing menghabiskan rata-rata 8 menit untuk dicari dan dijawab, itu lebih dari lima jam kerja per hari, sekitar dua pertiga dari satu orang penuh, yang seluruhnya dihabiskan memindahkan informasi yang sudah ada.

Dasar kedua: ketidakpuasan lahir dari selisih, bukan dari kinerja

Model kesenjangan kualitas layanan yang dikembangkan Parasuraman, Zeithaml, dan Berry menjelaskan sesuatu yang sering membingungkan manajemen: kenapa customer bisa tidak puas meskipun kinerja operasionalnya baik.

Inti modelnya: kepuasan bukan fungsi dari kinerja absolut, melainkan dari selisih antara apa yang diharapkan dan apa yang dipersepsi diterima. Kinerja yang sama bisa menghasilkan kepuasan atau kekecewaan, tergantung harapan yang terbentuk sebelumnya.

Ini punya dua implikasi langsung untuk portal:

• Ketidaktahuan menaikkan persepsi buruk. Customer yang tidak tahu di mana barangnya akan mengisi kekosongan itu dengan dugaan, dan dugaan manusia dalam ketidakpastian cenderung ke arah negatif. Pengiriman yang berjalan normal bisa dipersepsi bermasalah semata karena senyap.
• Janji yang berlebihan menaikkan harapan, dan karena itu memperlebar selisih. Portal yang menjanjikan 'pelacakan real-time' untuk pengiriman laut sedang menaikkan harapan ke tingkat yang datanya tidak akan sanggup penuhi. Kekecewaan yang muncul bukan karena kinerja buruk, tapi karena janji yang tidak proporsional.

“Portal tidak membuat pengiriman lebih cepat. Ia membuat pengiriman yang berjalan normal berhenti terasa mencurigakan.”

Yang perlu ada, diurutkan dari yang paling banyak memotong pertanyaan

Urutan ini diturunkan dari satu prinsip: dahulukan yang paling sering ditanyakan, karena itulah yang menurunkan λ paling banyak per satuan usaha.

1. 1Status pengiriman berjalan, dengan waktu pembaruan terakhir. Ini menjawab mayoritas pertanyaan. Cantumkan umur datanya, tanpa itu, customer tidak bisa menilai apakah informasi yang dilihatnya masih relevan.
2. 2Dokumen yang bisa diunduh sendiri. POD, surat jalan, invoice. Ini kelompok pertanyaan kedua terbesar, dan yang paling memakan waktu untuk dilayani secara manual.
3. 3Riwayat pengiriman yang bisa dicari. Sering dibutuhkan saat customer menyusun laporan internal atau menghadapi audit. Tanpa ini, permintaan datang dalam bentuk 'tolong kirimkan rekap tiga bulan', yang memakan waktu berjam-jam.
4. 4Status penagihan. Invoice mana sudah terbit, mana sudah dibayar. Mengurangi bolak-balik antara finance kedua pihak.
5. 5Formulir permintaan pengiriman baru. Baru berguna setelah empat hal di atas dipakai; kalau ditaruh pertama, portal jadi terasa seperti pekerjaan tambahan bagi customer.

Kesalahan yang paling merusak: data usang yang terlihat baru

Kalau portal menampilkan status yang tidak diperbarui sejak tiga hari lalu tanpa menjelaskannya, customer akan menyimpulkan salah satu dari dua hal: barangnya tersangkut, atau sistem Anda tidak bisa dipercaya. Keduanya buruk, dan keduanya menghasilkan telepon, persis yang hendak dihindari.

Dilihat dari model kesenjangan layanan, ini kasus di mana intervensi justru memperlebar selisih: Anda menaikkan harapan dengan menyediakan portal, lalu gagal memenuhinya. Hasilnya lebih buruk daripada sebelum portal ada.

Soal hak akses, yang sering diremehkan

Portal berarti membuka sebagian data Anda ke pihak luar. Ini menuntut kejelasan yang tidak dibutuhkan sistem internal:

• Setiap customer hanya boleh melihat pengirimannya sendiri, dan pembatasan ini harus ditegakkan di sisi server, bukan hanya disembunyikan di tampilan.
• Customer tidak boleh melihat tarif beli Anda dari vendor, hanya harga jual yang berlaku baginya.
• Pengguna di sisi customer sering berganti. Harus ada cara menonaktifkan akses tanpa menghubungi Anda, atau minimal proses yang jelas.
• Data pengiriman memuat informasi komersial yang sensitif bagi customer Anda. Kebocoran ke customer lain adalah kegagalan yang sulit dipulihkan hubungannya.

Poin pertama layak diperiksa secara khusus saat mengevaluasi vendor. Sistem yang menyaring data di sisi tampilan tetapi mengirim seluruh data ke browser bukanlah sistem yang membatasi akses, ia hanya menyembunyikannya, dan penyembunyian itu bisa dilewati siapa pun yang tahu caranya.

Mengukur keberhasilan: turunnya λ, bukan naiknya login

Ukuran yang sering dipakai (jumlah pengguna aktif, jumlah login) sebenarnya tidak mengukur apa pun yang Anda inginkan. Portal yang sukses justru bisa menghasilkan sedikit login, kalau informasinya cukup jelas sehingga customer tidak perlu memeriksa berulang kali.

Yang relevan, sesuai kerangka di awal tulisan ini, adalah λ: laju pertanyaan yang masuk ke tim Anda.

Ambil garis dasar sebelum portal diluncurkan, hitung pertanyaan status yang masuk selama dua minggu. Tanpa angka itu, Anda tidak akan bisa membuktikan apa pun setelahnya, dan portal akan dinilai berdasarkan kesan, yang selalu kalah oleh keluhan segelintir orang yang paling vokal.