Kenapa Kami Bangun Fitur Override Manager — dan Filosofi Trust vs Control di Baliknya

Awalnya Kami Nggak Mau Bangun Fitur Ini

Waktu pertama kali desain CrescendPOS, kami sengaja nggak taruh fitur "manager override" di roadmap V1 awal. Alasannya simpel: rasanya terlalu korporat. POS kami didesain untuk kafe kecil dan kedai, bukan chain restaurant dengan 200 cabang. Apakah kedai kopi dengan 3 karyawan benar-benar butuh "approval flow"?

Ternyata, jawabannya iya — tapi bukan karena alasan yang kami kira.

Masalah yang Ternyata Lebih Umum dari yang Kami Pikir

Dari percakapan kami dengan pemilik kafe, ada pola yang terus muncul:

• Kasir salah input pesanan — harga atau produk yang keliru — dan nggak bisa batalin sendiri. Mereka harus tunggu owner datang, yang kadang baru bisa besok.
• Ada void atau pembatalan yang memang legitimate, tapi nggak ada record siapa yang approve dan kenapa. Kalau ada selisih kas di akhir hari, nggak ada trail-nya.
• Owner mau kasih trust ke kasir senior untuk handle situasi tertentu, tapi nggak mau kasih akses penuh ke semua fitur. Nggak ada middle ground.

Ini bukan masalah "trust issue" — ini masalah nggak ada mekanisme yang proper untuk situasi di luar normal flow.

Filosofi yang Kami Pegang: Trust + Guard Rails

Ada dua extreme dalam desain permission:

• Full trust: Semua orang bisa melakukan apapun. Simple, tapi kalau ada masalah, nggak ada accountability. Dan yang lebih penting, kasir jadi "menanggung" semua risiko — kalau mereka bikin keputusan yang salah, nggak ada sistem yang melindungi mereka.
• Full control: Setiap tindakan butuh approval. Secure, tapi lambat dan bikin frustasi. Kasir nggak bisa kerja dengan efisien, dan manager jadi bottleneck.

Kami pilih jalan tengah: trust by default, guard rails for exceptions.

Artinya: untuk flow normal (tambah pesanan, proses pembayaran, tutup shift), kasir punya full autonomy. Nggak ada approval yang diperlukan. Tapi untuk aksi yang di luar normal flow — void, pembatalan, diskon manual, akses laporan sensitif — ada mekanisme override yang tercatat.

Kenapa Override Itu Melindungi Kasir, Bukan Membatasi

Ini perspektif yang sering kelewat: override bukan cuma melindungi bisnis dari kasir. Override juga melindungi kasir dari situasi awkward.

Bayangkan skenario ini: customer marah dan minta refund. Tanpa sistem override, kasir harus bikin keputusan sendiri — approve refund atau tolak customer yang marah. Kalau kasir approve dan owner nggak setuju, kasir yang kena. Kalau kasir tolak dan customer bikin scene, kasir juga yang kena.

Dengan override, kasir punya jawaban yang clear dan professional: "Saya perlu approval manager untuk ini." Tekanan diambil dari pundak kasir dan ditaruh di sistem yang proper.

Gimana Kami Implementasinya

Beberapa keputusan desain yang kami buat:

• Override di level aksi, bukan di level halaman. Kasir nggak "diblokir" dari halaman tertentu — mereka bisa lihat interface-nya, tapi aksi spesifik yang butuh privilege lebih tinggi akan minta approval. Ini lebih natural dan nggak bikin kasir merasa dibatasi.
• PIN-based approval. Manager nggak perlu login ke device kasir. Cukup masukin PIN manager di prompt yang muncul. Cepat, practical, dan nggak ganggu flow operasi.
• Semua override tercatat. Siapa yang minta, siapa yang approve, kapan, dan untuk aksi apa. Ini bukan untuk "mengawasi" — ini supaya kalau ada pertanyaan di kemudian hari, jawabannya sudah ada.
• Configurable per tenant. Nggak semua bisnis butuh level of control yang sama. Kedai kecil dengan 1 kasir mungkin cuma butuh override untuk void. Kafe yang lebih besar mungkin mau lebih banyak guard rails. Kami bikin ini bisa di-set sesuai kebutuhan.

Keputusan yang Kami Perdebatkan Paling Lama

Pertanyaan paling susah bukan "aksi apa yang butuh override" — tapi seberapa mudah override itu dilakukan.

Kalau terlalu mudah (misalnya cuma klik "confirm"), override jadi meaningless — orang cuma asal klik tanpa mikir. Tapi kalau terlalu rumit (misalnya harus scan QR + input alasan + foto bukti), nggak ada yang mau pakai dan orang akan cari jalan lain.

Kami settle di PIN entry + alasan opsional. PIN itu cukup untuk membuktikan "orang yang berwenang sadar dan setuju". Alasan opsional karena di saat rush hour, kamu nggak mau memaksa manager nulis esai sebelum approve void.

Apa yang Kami Pelajari Setelah Launch

Beberapa observasi setelah fitur ini live:

• Kasir lebih tenang. Mereka tahu bahwa untuk situasi di luar normal, ada prosedur yang jelas. Nggak perlu "nebak" keputusan sendiri.
• Selisih kas berkurang. Bukan karena kasir nggak bisa "curang" — tapi karena setiap void dan pembatalan sekarang punya trail yang jelas. Kesalahan genuine lebih gampang diidentifikasi dan diperbaiki.
• Owner punya visibility tanpa harus selalu ada. Mereka bisa review override log dari rumah dan tahu apa yang terjadi tanpa harus physically hadir.

Bukan Soal Trust Issue

Kami sering dengar: "Kalau saya pakai fitur override, berarti saya nggak percaya kasir saya dong?"

Kebalikannya. Override itu expression of trust. Kamu trust kasir untuk handle normal flow tanpa pengawasan. Dan kamu bikin sistem yang melindungi mereka waktu situasi jadi abnormal — sehingga mereka nggak perlu menanggung risiko keputusan yang seharusnya di level managerial.

Ini sama kayak kenapa perusahaan punya approval chain untuk pengeluaran besar. Bukan karena nggak percaya karyawan — tapi karena keputusan besar seharusnya melibatkan orang yang punya konteks dan authority yang cukup.

Permission layer yang baik bukan membatasi — tapi membebaskan semua orang untuk bekerja di scope mereka dengan confident.