Sistem booking itu bukan kalender

Pertanyaannya muncul di salon, klinik kecantikan, studio foto, bengkel, pet care, sampai restoran yang terima reservasi. Bentuknya hampir selalu sama: sistem booking apa yang bagus? Sekarang masih lewat WhatsApp dan mulai berantakan. Jawaban yang datang hampir selalu nama aplikasi.

Yang jarang ditanyakan justru yang menentukan aplikasi itu cocok atau tidak: apa yang terjadi di hari sistemnya salah. Dua orang datang untuk jam yang sama. Tamu yang sudah DP tidak datang dan minta uangnya kembali. Tamu yang tidak datang membantah tagihannya ke bank.

Satu kasus yang baru saya temui memperlihatkan ini dengan jelas. Seorang pemilik usaha yang menerima reservasi ingin menahan DP dari kartu tamu asing waktu reservasi, menagihnya kalau tamu tidak datang, dan membatalkannya kalau tamu datang. Kedengarannya satu fitur. Ternyata di dalamnya ada tiga masalah yang terpisah, dan cuma satu yang urusan kalender.

Kalau booking masih lewat WhatsApp, kalendernya ada di kepala admin. Begitu adminnya dua, atau booking juga masuk lewat DM Instagram dan tamu yang datang langsung, ada jeda antara slot dijanjikan dan slot dicatat. Di jeda itulah dua orang mendapat jam yang sama, dan biasanya baru ketahuan di hari H.

Masalah kedua lebih halus. Slot itu bukan jam. Slot itu orang dikali durasi, kadang ditambah ruangan atau alat. Treatment 90 menit jam 14.00 memakai terapisnya sampai 15.30, dan kalau butuh ruang khusus, ruangan itu juga terpakai. Kalender yang hanya mencatat jam mulai akan dengan senang hati menerima booking kedua jam 15.00.

Sistem booking yang benar menghitung ketersediaan dari jam kerja tiap staf dikurangi janji yang sudah ada, lalu baru menawarkan slot. Pelanggan tidak memilih jam, pelanggan memilih dari jam yang memang masih kosong.

Ini bagian yang paling sering salah paham, karena “DP” dipakai untuk dua hal yang sangat berbeda.

• DP lewat QRIS, virtual account, atau transfer adalah uang yang sudah masuk. Tidak ada tahap “tahan dulu” di instrumen ini. Kalau tamu batal dan berhak dapat uangnya kembali, yang terjadi adalah refund, dan cara serta biayanya tergantung payment gateway yang kamu pakai.
• Hold kartu kredit adalah hal yang lain. Bank penerbit memblokir sejumlah dana tanpa menagihnya. Kalau tamu datang, hold dibatalkan dan tamu bayar normal. Kalau tamu tidak datang, hold itu ditagih.

Hold kartu kedengarannya jawaban yang sempurna, sampai kamu tahu satu hal: hold itu ada umurnya. Di dokumentasi Xendit dan Midtrans, otorisasi yang tidak ditagih lepas sendiri setelah sekitar 7 hari. Tamu yang booking dua minggu sebelumnya tidak bisa ditahan saat booking, karena hold-nya sudah lepas jauh sebelum tanggal datang.

Pola yang bekerja untuk booking jauh hari ada empat langkah:

• Saat booking, kartu disimpan sebagai token, belum ada dana yang ditahan.
• H-2, sistem membuat hold dari kartu yang disimpan tadi.
• Tamu datang, hold dibatalkan supaya tidak dobel dengan pembayaran di kasir.
• Lewat jam reservasi dan tamu belum datang, baru hold ditagih.

Yang jarang dibilang: langkah kedua, membuat hold tanpa tamu hadir, bukan setelan bawaan. Di Xendit, menagih kartu tersimpan atas inisiatif merchant perlu persetujuan tim risk mereka. Di Midtrans, kartu tersimpan yang ditagih tanpa tamu memasukkan CVV butuh MID recurring dari bank. Dua-duanya bisa diajukan, tapi harus diajukan, dan payment gateway tidak tahu jadwal reservasimu. Yang menjalankan langkah H-2 sampai tagih itu sistem booking-mu sendiri.

Kartu punya satu sifat yang tidak dimiliki QRIS atau transfer: uangnya bisa ditarik balik. Pemegang kartu yang merasa tagihannya tidak sah bisa mengajukan sengketa ke banknya, dan tagihan no-show adalah jenis tagihan yang paling mungkin dibantah. Dari sisi tamu, dia tidak menerima apa-apa.

Banyak yang mengira 3D Secure, langkah OTP saat bayar, melindungi dari ini. Tidak. Perlindungan 3DS hanya berlaku untuk sengketa penipuan, yaitu ketika pemegang kartu bilang dia tidak pernah melakukan transaksi itu. Sengketa “saya sudah membatalkan” atau “saya tidak tahu ada kebijakan itu” tetap jadi urusanmu.

Dalam sengketa seperti itu, yang biasanya diminta dari merchant adalah bukti bahwa pemegang kartu sudah diberi tahu kebijakannya dan menyetujuinya. Artinya sistem booking perlu menyimpan tiga hal untuk tiap booking: teks kebijakan versi mana yang ditampilkan, kapan pelanggan menyetujuinya, dan booking mana yang terkait. Tangkapan layar chat WhatsApp yang berbunyi “ok kak” jauh lebih lemah dari itu.

Ini bagian yang tidak terasa penting sampai sengketa pertama datang, dan pada saat itu sudah terlambat untuk mulai mencatat.

Demo dari vendor selalu disiapkan untuk berhasil. Empat tes ini disiapkan untuk gagal, dan itu satu-satunya cara membandingkan dua aplikasi dengan jujur. Jalankan dengan layanan dan staf yang sungguhan, sebelum berkomitmen ke apa pun.

Bagian ini yang jarang ada di balasan vendor, jadi saya tulis terang-terangan. Kalau kamu mengerjakan sendiri, booking-nya beberapa per hari, dan tidak ada DP, kamu belum punya masalah ini. Kalender bersama dan template balasan WhatsApp sudah cukup, dan gratis.

Kalau stafnya sudah beberapa, ada DP, dan layanannya standar, beli aplikasi booking dulu sebelum membangun. Kategori ini sudah matang, dan di skala kecil aplikasi jadi hampir selalu lebih baik dari apa pun yang dipesan khusus. Pakai empat tes di atas untuk memilih. Saya sengaja tidak menulis daftar aplikasi, harga, atau peringkat: semua itu berubah tiap bulan dan daftarnya sudah salah sebelum sempat berguna.

Membayar developer untuk membangun ulang aplikasi booking standar adalah cara paling mahal untuk mendapat versi yang lebih buruk. Saya bilang ini sebagai developer yang akan kamu bayar.

Garisnya ada, dan bukan soal jumlah booking. Soalnya apakah aturan bisnismu muat di aplikasi jadi.

• Kebijakan DP yang khas. Hold kartu yang dibuat H-2 untuk tamu yang booking jauh hari, aturan hangus yang berbeda per layanan, atau DP yang sebagian dikembalikan. Aplikasi jadi biasanya punya satu aturan untuk semua.
• Sumber daya lebih dari satu. Satu layanan butuh terapis, ruangan, dan alat sekaligus, dan ketiganya harus kosong di jam yang sama.
• Booking harus nyambung ke sistem yang sudah ada. Kasir, CRM, atau data member yang tidak bisa dipindah ke aplikasi booking.

Itu bentuk sistem yang saya bangun. Alur booking publik dengan jadwal yang dihitung dari jam kerja terapis dan janji yang sudah ada, tanpa double booking, plus panel admin dengan kalender harian dan riwayat pelanggan, ada di Seruni untuk salon, dan versi klinik dengan dokter di AIVELLE. Keduanya demo yang saya bangun dan miliki, dengan data contoh, bukan proyek klien. Keduanya juga belum memproses pembayaran: DP dan hold kartu adalah tahap produksi, bukan bagian dari demo.

Yang belum pernah saya lakukan adalah menjalankan alur hold kartu dan tagihan no-show secara live untuk klien. Mekanismenya berasal dari dokumentasi payment gateway dan dari membangun sistem booking. Kalau kamu butuh orang yang sudah bertahun-tahun mengurus sengketa kartu, itu permintaan yang wajar, dan orangnya bukan saya.

Kalau masalahmu bukan booking tapi stok yang berantakan antar marketplace, logika yang sama, tiga masalah dalam satu nama, ada di tulisan saya soal sinkron stok.