
Esai
Aplikasi Driver Ditinggalkan Bukan Karena Driver Susah Berubah
Aplikasi driver jarang gagal karena kurang fitur. Yang kami perhatikan berulang di beberapa armada berbeda: yang menentukan apakah aplikasi itu bertahan atau ditinggalkan adalah jumlah ketukan layar untuk menyelesaikan satu pengiriman, dan apa yang terjadi di aplikasi itu begitu sinyal hilang di titik bongkar.
Ditulis oleh Tim Editorial CargoGrid. Catatan ini disusun dari pengamatan tim CargoGrid saat mendampingi peluncuran aplikasi driver di beberapa armada trucking dan 3PL, bukan dari satu studi kasus tunggal.
- Ketukan dan ketikan yang dibutuhkan per pengiriman adalah ukuran paling jujur untuk menilai apakah aplikasi driver akan bertahan atau ditinggalkan, dan paling gampang dihitung sendiri.
- Manfaat yang dihitung manajemen (piutang cair lebih cepat, laporan rapi) tidak serta-merta terasa oleh driver; yang terasa langsung adalah bukti kerja yang melindungi dirinya, kepastian uang jalan, dan lebih sedikit telepon dari kantor.
- Mode offline bukan fitur tambahan. Satu kali gagal simpan data saat sinyal hilang di titik bongkar sudah cukup membuat driver cenderung kembali memotret POD dengan kamera biasa untuk seterusnya.
- Peluncuran bertahap ke kelompok kecil dulu, baru diperluas lewat cerita dari sesama driver, jauh lebih tahan lama dibanding peluncuran serentak ke seluruh armada.
Kalau harus menunjuk satu sebab paling sering kenapa aplikasi driver yang sudah dibeli mahal-mahal berhenti dipakai beberapa bulan setelah diluncurkan, kami akan menunjuk ke dua hal yang sangat teknis: jumlah ketukan layar untuk menyelesaikan satu pengiriman, dan apa yang terjadi di aplikasi itu begitu sinyal hilang di titik bongkar. Bukan sikap driver.
Pola yang kami lihat berulang di beberapa armada berbeda kurang lebih sama: bulan pertama terasa seperti kemenangan, aplikasi terpasang di semua ponsel, tim ops sudah dilatih, dan dua minggu pertama semua orang memakainya dengan rajin. Lalu pelan-pelan berubah. Update status mulai telat, foto POD mulai kosong, dan tiga bulan kemudian koordinasi lapangan diam-diam kembali ke WhatsApp dan telepon seperti sebelum aplikasi itu ada, sementara tagihan langganannya tetap terpotong setiap bulan, dipakai atau tidak.
Diagnosis yang paling sering muncul di rapat evaluasi adalah “driver kami memang susah diajak berubah.” Diagnosis ini terasa aman diucapkan karena tidak ada yang harus disalahkan di ruangan itu. Tapi dari yang kami amati langsung di lapangan, diagnosis itu jarang tepat. Yang terjadi di lapangan biasanya jauh lebih spesifik dan jauh lebih bisa diperbaiki: soal berapa kali layar harus disentuh, dan apa yang terjadi begitu sinyal hilang.
Yang terjadi di layar driver, bukan di rapat evaluasi
Coba hitung sendiri di aplikasi yang sedang dipakai sekarang: dari membuka aplikasi sampai satu pengiriman tercatat selesai lengkap dengan foto dan tanda tangan, berapa kali layar itu harus disentuh? Di beberapa aplikasi yang pernah kami tinjau, angkanya bisa sampai dua belas ketukan atau lebih: ada field wajib yang harus diisi urutan tertentu, ada dropdown yang harus dicari manual, ada langkah konfirmasi yang berulang. Bandingkan dengan cara yang diam-diam menang selama ini: memotret POD lalu mengirim ke grup WhatsApp, kira-kira cuma lima ketukan.
“Aplikasi driver tidak bersaing dengan aplikasi driver lain. Pesaingnya adalah WhatsApp, dan WhatsApp itu gampang sekali dipakai.”
Ini yang menurut kami sering luput dari rapat evaluasi: driver menilai kemudahan secara relatif, dibandingkan dengan cara yang sudah ia kuasai. Aplikasi dengan dua belas ketukan akan kalah oleh kebiasaan lima ketukan, seberapa pun lengkap data yang dihasilkannya. Kekalahannya juga terjadi diam-diam, tanpa penolakan yang pernah diucapkan terbuka. Driver jarang mengeluh ke atasan bahwa aplikasinya ribet; ia cuma pelan-pelan berhenti memakainya di momen-momen yang tidak diawasi.
Sinyal hilang justru di titik yang paling penting
Banyak titik bongkar di Indonesia duduk di kawasan industri, di dalam gudang berdinding beton tebal, atau di area pelabuhan, tempat sinyal selulernya memang tidak bisa diandalkan. Untuk sebagian rute yang kami amati, ini bukan pengecualian langka, melainkan kondisi sehari-hari yang harus diperhitungkan sejak rancangan awal.
Yang paling menentukan bukan seberapa sering sinyal hilang, tapi apa yang terjadi persis di momen itu. Kami pernah melihat kejadian yang polanya berulang: driver sudah menyerahkan barang, penerima sudah menunggu tanda tangan di layar, tapi aplikasinya cuma berputar-putar dan menolak menyimpan data karena tidak ada koneksi. Satu kejadian seperti itu meninggalkan bekas yang jauh lebih dalam ketimbang sepuluh kali berhasil berturut-turut. Sesudahnya, driver mulai memotret POD pakai kamera biasa “buat jaga-jaga saja”. Begitu kebiasaan itu terbentuk, aplikasinya sudah kalah: ia jadi pekerjaan tambahan di atas cara lama, bukan pengganti cara lama.
Ada satu lapisan lagi yang sering terlewat di rapat evaluasi: perangkatnya sendiri. Sebagian besar driver di armada milik sendiri sekarang sudah punya ponsel Android yang cukup memadai, jadi menyediakan ponsel khusus jarang jadi keharusan. Yang justru sering jadi kendala nyata adalah versi Android minimum dan ukuran instalasi aplikasinya: ponsel lama dengan penyimpanan tersisa beberapa ratus megabyte akan menolak update, dan driver tidak akan melapor soal itu, ia cuma diam-diam berhenti membuka aplikasinya. Untuk subkontraktor, memaksakan perangkat khusus pula hampir selalu berujung penolakan, karena ponsel itu miliknya sendiri, bukan aset perusahaan yang bisa diatur begitu saja.
Karena itu, penyimpanan lokal dan sinkronisasi otomatis begitu koneksi kembali, menurut pengamatan kami, tidak bisa ditunda ke fase kedua peluncuran. Keduanya syarat supaya fase pertama punya kesempatan berhasil sama sekali.
Yang benar-benar terasa oleh driver, bukan oleh kantor
Manfaat yang dihitung manajemen dalam proposal (piutang cair lebih cepat, klaim yang berkurang, laporan yang lebih rapi) semuanya jatuh ke perusahaan. Tidak satu pun dari angka-angka itu menyentuh driver secara langsung, dan itu masuk akal, karena driver bukan yang membeli aplikasinya, ia cuma yang memakai. Dari yang kami lihat berulang di lapangan, ada empat hal yang justru terasa langsung oleh driver, dan keempatnya sudah lama jadi keluhan sebelum aplikasinya ada:
- Bukti kerja yang tak terbantahkan. Driver sering kena tuduhan kehilangan POD, atau dituduh mengaku sudah mengantar padahal belum sampai. Kalau aplikasinya otomatis menyimpan foto dan jam kejadian, catatan itu melindungi driver itu sendiri saat terjadi perselisihan, sesuatu yang jauh lebih ia butuhkan ketimbang sekadar dianggap alat pengawasan dari kantor.
- Kepastian uang jalan atau komisi cair. Begitu penyelesaian pekerjaan tercatat otomatis dan langsung memicu perhitungan pembayaran, driver punya alasan sendiri untuk memastikan catatannya akurat. Uangnya bergantung pada itu.
- Telepon dari kantor jadi lebih jarang. Status yang ia isi sendiri bisa menjawab pertanyaan yang biasanya diulang berkali-kali lewat telepon: posisi di mana, sudah bongkar belum, kapan sampai. Menukar satu ketukan dengan beberapa telepon yang tidak perlu itu tawaran yang gampang diterima siapa saja.
- Rute dan alamat yang jelas. Ini menghemat waktu yang sungguhan berharga, terutama untuk lokasi baru yang belum pernah ia datangi, dan waktu adalah mata uang yang paling dihargai driver.
Perhatikan polanya: tidak satu pun berupa fitur pelacakan. Pelacakan adalah manfaat yang dirasakan kantor, bukan driver, dan dari pengamatan kami, aplikasi yang terlalu menonjolkan fungsi ini justru terasa seperti bentuk pengawasan di mata pemakainya, walau fungsinya sendiri sebetulnya netral.
Cara memperkenalkannya yang kami lihat berhasil
Urutan berikut bukan teori yang kami terapkan dari buku, tapi pola yang berulang setiap kali sebuah peluncuran berjalan lebih mulus dibanding yang lain:
- 1Mulai dari kelompok kecil yang memang mau mencoba, jangan langsung ke seluruh armada sekaligus. Lima sampai delapan driver yang relatif nyaman pakai ponsel saja sudah cukup untuk memulai.
- 2Perbaiki dulu berdasarkan keluhan kelompok kecil ini, baru perluas ke driver lain. Keluhan di tahap awal ini data paling berharga yang bisa dikumpulkan, dan jauh lebih murah ditindaklanjuti sekarang dibanding setelah armada besar terlanjur memakainya.
- 3Biarkan mereka bercerita ke rekan-rekannya sendiri. Driver yang dengar langsung dari sesama driver bahwa aplikasi ini betul-betul membantu akan jauh lebih percaya, dibanding mendengar hal yang sama dari instruksi manajemen.
- 4Tetapkan tanggal pasti berhentinya cara lama, dan umumkan jauh-jauh hari. Masa transisi tanpa batas waktu yang jelas hampir selalu dimenangkan kebiasaan lama, karena begitu situasi sibuk, orang cenderung kembali ke cara yang paling ia kuasai.
Pola yang paling sering kami lihat, dan akibatnya
| Yang terjadi | Kenapa itu terjadi | Akibatnya di lapangan |
|---|---|---|
| Meluncurkan ke seluruh armada dalam satu waktu | Tidak ada kelompok kecil yang menyerap masalah lebih dulu | Masalah kecil membesar jadi penolakan massal |
| Mewajibkan terlalu banyak field isian | Setiap field terasa menambah beban, bukan menambah manfaat | Driver mengisi asal-asalan supaya cepat selesai, data pun jadi tidak bisa dipercaya |
| Terlalu menonjolkan fungsi pelacakan | Terasa seperti pengawasan, bukan bantuan | Driver mencari cara diam-diam menghindarinya |
| Melatih sekali di awal lalu dibiarkan begitu saja | Driver baru tidak pernah kebagian pelatihan | Adopsi pelan-pelan meluruh seiring pergantian driver |
| Tidak menyediakan mode offline | Satu kali gagal di momen genting sudah cukup merusak kepercayaan | Driver kembali ke kamera biasa dan WhatsApp “buat jaga-jaga” |
| Membiarkan jalur WhatsApp tetap jadi jalur resmi | Tidak ada titik henti yang jelas untuk cara lama | Jalur yang paling gampang hampir selalu menang |
Baris terakhir di tabel itu layak digarisbawahi tersendiri. Selama koordinator masih menerima foto POD lewat WhatsApp dan langsung memprosesnya tanpa banyak tanya, WhatsApp pada praktiknya masih menjadi sistem resmi perusahaan, dan aplikasi barunya cuma akan dipakai oleh driver yang paling patuh saja. Menutup jalur lama memang terasa berat untuk diputuskan. Tapi tanpa keputusan itu, perubahan itu jarang bertahan. Menutupnya jadi jauh lebih ringan begitu kelompok kecil di awal tadi sudah membuktikan bahwa cara barunya memang bekerja.
Kalau mau menaruh nama pada pola ini
Semua yang kami tulis di atas berasal dari pengamatan berulang, bukan dari teori yang kami baca lalu dicocok-cocokkan ke lapangan. Tapi kalau mau menaruh nama yang lebih formal: yang kami sebut “terasa lebih ringan” itu di literatur akademik disebut perceived usefulness, dan “jumlah ketukan” yang kami hitung tadi adalah proksi kasar untuk perceived ease of use. Keduanya dua variabel utama dalam Technology Acceptance Model, model yang dirumuskan Fred Davis akhir 1980-an dan sudah diuji ulang di ratusan konteks berbeda sejak itu. Urutan pengenalan bertahap yang kami jabarkan di atas juga punya nama sendiri: mirip dengan yang dijelaskan Everett Rogers lewat teori difusi inovasi, tentang bagaimana praktik baru menyebar dari sekelompok kecil pengadopsi awal ke mayoritas lewat pengaruh sesama anggota kelompok, bukan lewat instruksi dari luar.
Bagi kami istilahnya berguna sebagai cara merangkum, bukan tempat memulai. Yang menentukan apakah aplikasi driver bertahan atau ditinggalkan tetap dua hal yang sama teknisnya sejak paragraf pertama tulisan ini: apa yang terjadi di layar driver, dan apa yang terjadi begitu sinyal hilang di titik bongkar.
Pertanyaan yang Sering Muncul
Apakah pelacakan lokasi terus-menerus benar-benar diperlukan?
Jarang. Untuk sebagian besar kebutuhan operasional, mencatat lokasi di titik-titik peristiwa penting saja (tiba di lokasi, mulai bongkar, selesai) sudah cukup menjawab hampir semua pertanyaan customer. Pelacakan terus-menerus menguras baterai ponsel, menimbulkan kekhawatiran soal privasi, dan dari yang kami amati justru bikin driver makin enggan memakainya.
Berapa lama sampai adopsinya bisa dibilang berhasil?
Patokan yang kami pakai adalah angka: berapa persen pengiriman yang tercatat lengkap lewat aplikasi setiap minggu. Kalau grafiknya naik lalu mendatar di bawah target, biasanya ada satu hambatan spesifik yang menahannya (perangkat tertentu, lokasi tertentu, atau jenis pengiriman tertentu), dan cara tercepat menemukannya adalah bertanya langsung ke driver dengan angka paling rendah.

