Ketika Perantara Menjadi Penghalang

Seorang pelancong baru-baru ini memesan penerbangan IndiGo melalui platform AirAsia MOVE. Ketika rencana berubah, ia meminta untuk membatalkan perjalanan tersebut. Maskapai setuju. Seharusnya itu menjadi akhir dari ceritanya. Sebaliknya, platform itu sendiri menolak untuk memproses pembatalan, membuat penumpang tersebut terkatung-katung di celah antara dua perusahaan. Ia meluapkan rasa frustrasinya di depan publik dan menyebut sistem tersebut tidak berguna dan bodoh. Kemarahannya sangat nyata, namun hal itu menunjukkan masalah yang berdampak pada jutaan pelancong yang mengandalkan agregator untuk mempermudah hidup mereka.

Insiden ini adalah peristiwa kecil dalam mesin besar perjalanan daring, namun ia membawa peringatan keras. Kita mengunduh aplikasi ini untuk menghindari kerumitan mengelola situs web maskapai, gerbang pembayaran, dan kode konfirmasi. Kita mengharapkan perantara untuk melancarkan proses, bukan malah menguncinya. Ketika sebuah platform tidak dapat mengeksekusi pembatalan yang telah disetujui oleh maskapai, platform tersebut gagal menjalankan satu-satunya tugas utamanya: menyampaikan informasi secara akurat dari pengguna ke penyedia layanan dan sebaliknya.

Apa yang Gagal

Detail kasus ini sangat sederhana, dan justru itulah yang membuatnya mengkhawatirkan. Penumpang tersebut tidak mempermasalahkan biaya tersembunyi atau memperdebatkan celah kebijakan. Ia melakukan tindakan standar—membatalkan penerbangan—dan menemui kesalahan yang seharusnya tidak ada. IndiGo menerima pembatalan tersebut. AirAsia MOVE tidak. Hasilnya adalah situasi lose-lose yang klasik. Pelancong tersebut kehilangan waktu dan ketenangan pikiran. Platform tersebut kehilangan kredibilitas.

Kegagalan semacam ini biasanya terjadi jauh di dalam sistem teknis yang tidak pernah dilihat oleh pelancong. Agen perjalanan daring dan superapps tidak menyimpan inventaris maskapai di server mereka sendiri. Mereka terhubung ke maskapai melalui application programming interfaces, atau API, yang mengirimkan data bolak-balik. Saat Anda mengetuk “cancel”, permintaan Anda dikirim dari ponsel ke backend agregator, lalu diteruskan ke sistem reservasi maskapai. Maskapai memperbarui status pemesanan dan mengirimkan konfirmasi. Agregator seharusnya segera mencerminkan perubahan tersebut dan memproses pengembalian dana atau kredit perjalanan Anda.

Di suatu titik dalam rantai tersebut, AirAsia MOVE macet. Mungkin API gagal mengambil (poll) status terbaru dari sistem IndiGo. Mungkin logika internal aplikasi mengandung aturan hardcoded yang mengesampingkan respons maskapai. Mungkin agen layanan pelanggan dapat melihat ketidaksesuaian di layar mereka tetapi tidak memiliki izin untuk memaksa pembatalan tersebut. Kita tidak tahu bug pastinya, tetapi kita tahu hasilnya: seorang manusia terjebak di dalam loop perangkat lunak, tidak dapat membatalkan transaksi yang telah disepakati oleh semua pihak untuk dibatalkan.

Mengapa Kepercayaan Mengikis Lebih Cepat daripada Perbaikan Kode

Pelancong menoleransi antarmuka yang kaku. Mereka menoleransi waktu pemuatan yang lambat. Namun, mereka tidak akan menoleransi ketidakberdayaan ketika uang dan rencana sedang dipertaruhkan. Pembatalan bukanlah permintaan yang sepele. Hal itu biasanya menyusul sebuah krisis—masalah medis, keadaan darurat keluarga, atau konflik pekerjaan yang tiba-tiba. Pengguna sudah merasa stres. Peran aplikasi adalah untuk mengurangi stres tersebut dengan menangani kompleksitas backend. Ketika aplikasi justru menambah hambatan baru, beban emosional yang ditimbulkan menjadi sangat besar.

Inilah mengapa kemarahan publik penumpang tersebut penting. Ia tidak mengeluh tentang poin loyalitas yang hilang atau notifikasi push yang terlambat. Ia menyebut platform tersebut tidak berguna karena, pada saat ia sangat membutuhkannya, platform itu justru secara aktif menghalangi permintaan yang sah. Kepercayaan pada layanan digital dibangun di atas keyakinan bahwa sistem akan menghormati niat Anda bahkan ketika keadaan berubah. Satu pelanggaran terhadap janji tersebut memberikan kerusakan yang lebih besar daripada yang dapat diperbaiki oleh sepuluh pemesanan yang lancar.

Masalah ini juga mengungkap titik buta strategis dalam cara banyak platform perjalanan dibangun. Tim teknik sering kali mencurahkan sumber daya ke bagian front end: pencarian cepat, kalender yang cantik, checkout satu ketukan, penawaran yang dipersonalisasi. Itulah fitur-fitur yang mendorong unduhan. Operasi pasca-pemesanan—perubahan, pembatalan, pengembalian dana—dianggap sebagai pemikiran belakangan. Mereka mendapatkan API yang lebih lama, pemantauan yang lebih sedikit, dan opsi fallback yang lebih sedikit. Namun, di situlah pengguna menemukan apakah sebuah aplikasi adalah alat yang sesungguhnya atau sekadar brosur yang mengkilap.

Apa yang Harus Dilakukan dengan Benar oleh Platform Perjalanan

Ada pelajaran jelas di sini bagi perusahaan mana pun yang berada di antara pelanggan dan maskapai.

Buat pembatalan semudah pemesanan. Jika pengguna dapat memesan kursi dalam tiga ketukan, mereka seharusnya dapat membatalkannya tanpa harus melewati labirin chatbot, menu tersembunyi, dan formulir yang tidak didukung. Alur pembatalan harus terlihat jelas, jujur mengenai biaya, dan bebas dari dark patterns yang membuat pelancong merasa bersalah atau bingung sehingga tetap mempertahankan reservasi yang tidak dapat mereka gunakan.

Bangun mekanisme manual override yang benar-benar berfungsi. Otomatisasi sangat luar biasa sampai ia gagal. Ketika terjadi konflik pengembalian API atau kesalahan sinkronisasi, agen layanan pelanggan harus memiliki wewenang dan antarmuka untuk turun tangan. Terlalu banyak platform yang merancang benteng otomatis penuh tanpa pintu untuk intervensi manusia. Agen akhirnya hanya membaca skrip, meminta maaf tanpa henti, dan mengajukan tiket ke dalam lubang hitam. Override yang berguna berarti agen dapat melihat persetujuan maskapai, mencocokkannya dengan pemesanan yang tersangkut, dan memproses pembatalan secara real-time.

Pastikan perangkat lunak tetap sinkron dengan realitas maskapai. Platform perjalanan perlu beralih dari pembaruan batch dan siklus polling yang lambat. Jika maskapai menandai tiket sebagai dapat dibatalkan, dapat dikembalikan dananya (refundable), atau dijadwalkan ulang, agregator harus mengetahuinya dalam hitungan menit, bukan jam. Hal ini memerlukan arsitektur webhook yang kuat, logika retry untuk kegagalan handshake, dan tugas rekonsiliasi yang menandai ketidakcocokan sebelum pengguna menemukannya. Platform seharusnya tidak pernah menjadi pihak terakhir yang mengetahui status produknya sendiri.

Apa yang Dapat Dilakukan Pelancong Sekarang

Sampai industri memperbaiki celah-celah ini, penumpang perlu melindungi diri mereka sendiri. Jika Anda memesan melalui aplikasi pihak ketiga mana pun, termasuk yang besar seperti AirAsia MOVE, simpanlah bukti tertulis. Ambil tangkapan layar nomor konfirmasi, kebijakan pembatalan, dan komunikasi apa pun dari maskapai. Ketahui kebijakan maskapai itu sendiri sebelum Anda membeli; beberapa maskapai mengizinkan perubahan langsung melalui situs web mereka bahkan untuk tiket yang dijual oleh mitra. Jika aplikasi gagal, hubungi maskapai secara langsung. Ketika unggahan publik mendapatkan perhatian, perusahaan cenderung bergerak lebih cepat daripada melalui saluran dukungan pribadi. Dan jika sejumlah uang yang signifikan tertahan, jangan ragu untuk melakukan eskalasi melalui forum perlindungan konsumen atau mekanisme chargeback.

Kesimpulan Utamanya

Pengalaman pelanggan bukanlah lapisan pemolesan yang Anda terapkan setelah kode ditulis. Ia adalah kode yang bekerja dengan benar saat situasi menjadi kacau. Platform pemesanan yang tidak dapat membatalkan penerbangan ibarat mobil tanpa gigi mundur. Mobil tersebut mungkin melaju ke depan dengan indah, tetapi cepat atau lambat Anda akan perlu mundur dari sebuah tempat.

Pelancong tidak meminta keajaiban. Mereka meminta alat yang menjalankan perintah dasar tanpa melakukan gaslighting kepada mereka. Kegagalan AirAsia MOVE dalam menghormati pembatalan yang telah diterima oleh IndiGo adalah pengingat bahwa kenyamanan hanya nyata jika seluruh alur kerja (pipeline) berfungsi. Sampai platform perjalanan berinvestasi sebesar mereka berinvestasi pada corong akuisisi (acquisition funnels) untuk keandalan pasca-pembelian, pengguna akan tetap waspada. Dan mereka memang seharusnya begitu.