Kenapa Kami Bangun Fitur Held Orders — dan Gimana Draft Pesanan Mengubah Rush Hour

Masalah yang Kelihatannya Kecil

Ini skenario yang terjadi setiap hari di hampir setiap kafe: customer di depan kasir masih bingung mau pesan apa. Di belakangnya ada 5 orang yang sudah tahu persis mau pesan apa. Apa yang kasir lakukan?

Tanpa held orders, kasir cuma punya dua opsi — keduanya buruk:

• Opsi A: Nunggu. Kasir nunggu customer selesai mikir. 5 orang di belakang nunggu. 30 detik jadi 2 menit. Antrian makin panjang.
• Opsi B: Skip. Kasir bilang "silakan mikir dulu ya" dan pindah ke customer berikutnya. Tapi sekarang kasir harus ingat: "customer tadi mau balik, dan dia udah pilih 2 item tapi belum selesai." Info ini ada di mana? Di kepala kasir. Yang sudah penuh dengan 10 hal lain.

Ini masalah yang kelihatannya kecil — tapi di jam sibuk, setiap customer yang "hold up" antrian itu ripple effect ke semua orang di belakangnya.

Apa yang Kami Bangun: Draft Pesanan yang Bisa Di-"Park"

Konsepnya simpel: kasir bisa memulai pesanan, lalu "park" (simpan sementara) tanpa harus selesai atau bayar. Pesanan tersimpan sebagai draft — bisa di-resume kapan saja, oleh kasir yang sama atau kasir lain.

Flow-nya:

• Customer A mulai pesan → kasir input 2 item → customer A masih mikir
• Kasir hold pesanan A → otomatis berpindah ke layar baru untuk customer baru
• Customer B pesan → kasir input → bayar → selesai
• Customer C pesan → kasir input → bayar → selesai
• Customer A kembali → kasir buka draft → lanjutkan dari 2 item yang tadi → selesai

Nggak ada yang hilang. Nggak ada yang harus diingat di kepala. Nggak ada customer yang menahan antrian.

Kenapa Ini Nggak Se-Simple yang Kelihatannya

Dari luar, held orders kelihatan straightforward: "ya tinggal simpan aja." Tapi ada keputusan desain yang kami perdebatkan cukup lama:

Pertanyaan 1: Berapa Lama Draft Bertahan?

Kalau draft bertahan selamanya, daftar held orders bakal penuh dengan pesanan abandoned yang nggak pernah di-resume — creating clutter. Kalau expired terlalu cepat, customer yang genuinely mau balik malah kehilangan pesanannya.

Kami settle di: draft bertahan sepanjang shift. Waktu shift ditutup, semua draft yang belum di-resume otomatis cleared. Ini masuk akal karena: kalau customer nggak balik sebelum shift selesai, kemungkinan besar mereka nggak akan balik.

Pertanyaan 2: Siapa yang Bisa Resume Draft?

Opsi A: hanya kasir yang membuat draft yang bisa resume. Ini "safe" tapi limiting — kalau kasir itu break atau shift-nya selesai, draft-nya stuck.

Opsi B: semua kasir bisa resume draft manapun. Ini lebih flexible dan cocok untuk realita operasi F&B di mana kasir sering bergantian.

Kami pilih Opsi B. Alasannya: di kafe kecil, kasir sering overlap atau bergantian. Draft yang terkunci ke satu orang itu bottleneck yang nggak perlu.

Pertanyaan 3: Gimana Kasir Tahu Draft Mana yang Mau Di-Resume?

Kalau ada 5 draft, kasir harus bisa identify mana punya customer yang balik. Kami pakai label — kasir bisa kasih nama atau catatan di draft ("Cewek baju merah", "Meja 3", "Andi"). Label ini opsional tapi sangat membantu waktu antrian ramai.

Efek yang Nggak Kami Antisipasi

Setelah held orders live, ada beberapa penggunaan yang nggak kami expect:

• Pre-order untuk meja. Pelayan pergi ke meja, input pesanan di tablet, hold — lalu customer konfirmasi dan kasir finalize. Ini flow yang nggak kami rancang tapi works natural.
• Pesanan bertahap. Customer pesan kopi dulu, 30 menit kemudian pesan makanan. Kasir resume draft yang sama, tambahkan item — sehingga semuanya dalam satu pesanan, satu struk.
• "Save my order." Customer yang mau bayar nanti (misalnya nunggu teman yang mau ikut patungan) bisa minta kasir hold pesanannya. Kasir lanjut serve customer lain.

Dampak ke Throughput

Kami nggak punya angka exact dari A/B test (karena ini fitur yang launched untuk semua user), tapi dari feedback pemilik kafe:

• Customer yang "blocking" antrian berkurang signifikan. Kasir nggak lagi terjebak nunggu satu customer — mereka bisa selalu productive.
• Kasir lebih confident di rush hour. Mereka tahu bahwa kalau ada customer yang belum siap, ada mekanisme yang proper — bukan improvisasi.
• Less mental load. Informasi pesanan yang belum selesai ada di sistem, bukan di kepala kasir. Ini bikin mereka bisa fokus ke customer yang ada di depan mereka right now.

Kenapa Fitur "Simpel" Sering Paling Impactful

Held orders nggak flashy. Nggak ada yang pernah beli POS karena fitur held orders. Tapi ini contoh dari filosofi desain kami: fitur yang paling impactful sering bukan yang paling visible — tapi yang menghilangkan friction yang paling sering terjadi.

Rush hour itu stress test untuk seluruh operasi kafe. Setiap friction di jam sibuk itu amplified — dan setiap friction yang dihilangkan itu juga amplified. Held orders menghilangkan satu friction (customer yang belum siap menahan antrian) yang terjadi multiple times per shift. Impact kecilnya berlipat ganda.

Intinya

Held orders itu fitur yang solve masalah spesifik: customer yang belum siap pesan seharusnya nggak menghentikan seluruh antrian. Solusinya simpel secara konsep (park pesanan, resume nanti), tapi ada nuance di implementasinya (berapa lama bertahan? siapa yang bisa resume? gimana identify draft?). Dan dampaknya — less blocking, less mental load, more throughput — terasa paling kuat justru di momen yang paling penting: rush hour.