Kenapa Kami Bangun Service Mode — dan Kenapa Kafe Perlu Pisahkan Dine-In dan Takeaway

Satu Pertanyaan Sederhana yang Mengubah Segalanya

"Makan di sini atau dibungkus?"

Pertanyaan ini diajukan di setiap kafe, setiap hari, puluhan kali. Dan jawabannya mengubah banyak hal — packaging, kadang harga (ada kafe yang beda harga dine-in dan takeaway), cara penyajian, bahkan prioritas kitchen.

Tapi di kebanyakan sistem kasir, informasi ini hilang. Pesanan masuk sebagai "1 Nasi Goreng, 1 Kopi Susu" — tanpa ada catatan apakah ini makan di tempat atau bawa pulang. Hasilnya?

• Dapur nggak tahu harus plating (dine-in) atau packaging (takeaway)
• Laporan nggak bisa breakdown berapa persen revenue dari dine-in vs takeaway
• Kamu nggak punya data untuk keputusan penting: "Apakah kita harus invest di area duduk yang lebih nyaman, atau fokus ke packaging yang lebih baik?"

Apa yang Service Mode Lakukan

Service mode di CrescendPOS adalah toggle sederhana di awal transaksi: Dine-In atau Takeaway. Satu tap, sebelum mulai input pesanan.

Dari satu tap itu, beberapa hal terjadi otomatis:

• Struk mencantumkan mode layanan. Dapur lihat "DINE-IN" atau "TAKEAWAY" di struk — mereka langsung tahu cara menyajikan.
• Laporan terpisah. Di analytics, kamu bisa filter penjualan by service mode. Lihat breakdown revenue: berapa dari dine-in, berapa dari takeaway.
• Data untuk keputusan. Setelah sebulan, kamu tahu: "60% revenue kita dari takeaway" — dan itu mengubah cara kamu mikir soal investasi (packaging > furniture).

Kenapa Ini Nggak Se-simple Kelihatannya

"Cuma toggle dine-in/takeaway, apa susahnya?" Secara teknis, memang simpel. Yang susah adalah keputusan desain di baliknya.

Mandatory atau Optional?

Pertanyaan pertama: apakah kasir harus pilih service mode di setiap transaksi, atau boleh skip?

Kalau mandatory: setiap transaksi punya data yang lengkap. Tapi kalau kafe kamu model counter service di mana 95% dine-in, klik extra di setiap transaksi itu annoying — menambah waktu di jam sibuk.

Kalau optional: kasir yang lupa atau malas skip, dan data kamu jadi nggak reliable.

Solusi kami: owner bisa on/off fitur ini per kafe. Kafe yang model-nya murni dine-in? Matikan saja, nggak perlu toggle. Kafe yang campuran dine-in + takeaway? Nyalakan, dan set default mode (misalnya default "Dine-In", tinggal ganti kalau takeaway).

Satu Toggle atau Banyak Opsi?

Kami awalnya mempertimbangkan lebih dari dua opsi: Dine-In, Takeaway, Delivery, Drive-Through. Tapi untuk V1, kami mundur ke dua saja: Dine-In dan Pickup/Takeaway.

Kenapa? Karena kebanyakan kafe kecil di Indonesia beroperasi di dua mode ini. Delivery biasanya lewat platform pihak ketiga (GoFood, GrabFood) yang punya sistem sendiri. Drive-through hampir nggak ada di kafe kecil.

Prinsip kami: bangun untuk kebutuhan yang ada, bukan untuk skenario hipotetis. Kalau nanti demand untuk mode tambahan jelas, kita tambahkan. Tapi nggak sekarang.

Dimana Toggle-nya?

Placement toggle di UI itu penting. Kami taruh di awal flow transaksi — sebelum kasir mulai input item. Kenapa?

• Kasir biasanya tanya "makan di sini atau bawa pulang?" di awal interaksi, bukan di akhir. UI harus match dengan alur percakapan natural.
• Kalau di akhir (sebelum bayar), kasir sering lupa karena sudah fokus ke pembayaran.
• Di awal, informasi langsung tersedia untuk struk yang dicetak — termasuk struk dapur yang keluar bersamaan dengan input pesanan.

Apa yang Kami Pelajari

Beberapa insight dari proses membangun fitur ini:

Data yang nggak ada sama bahayanya dengan data yang salah. Sebelum ada service mode, banyak pemilik kafe yang "merasa" kebanyakan revenue dari dine-in — padahal setelah tracking, takeaway bisa jadi 40-50%. Feeling itu unreliable; data itu reliable.

Fitur kecil bisa punya dampak besar ke keputusan bisnis. Satu toggle yang bikin kamu tahu "weekend kebanyakan takeaway, weekday kebanyakan dine-in" bisa mengubah strategi staf (lebih banyak di packaging area vs di floor) dan strategi menu (menu yang travel well untuk takeaway vs yang butuh plating cantik untuk dine-in).

Simplicity is a feature. Kami bisa bikin service mode yang super advanced — dengan pricing berbeda per mode, packaging cost yang otomatis ditambahkan, workflow kitchen yang berbeda. Tapi untuk V1, satu toggle simpel sudah solve 80% dari masalah. Advanced features bisa datang nanti kalau demand-nya jelas.

Kenapa Ini Penting untuk Kafe Kamu

Kalau kafe kamu punya campuran dine-in dan takeaway (dan kebanyakan kafe di Indonesia memang begitu), memisahkan data kedua mode ini memberikan visibility yang sebelumnya nggak ada:

• Staffing decisions. Kalau 70% traffic sore itu takeaway, kamu butuh packaging speed lebih dari floor service.
• Menu decisions. Menu yang sering di-takeaway tapi nggak travel well (es cream yang melt, nasi yang soggy) = kandidat untuk diperbaiki atau diganti.
• Layout decisions. Apakah kamu perlu area pickup yang lebih besar? Atau lebih banyak meja duduk? Data service mode jawab ini.
• Revenue understanding. "Omzet bulan ini turun 10%" jadi lebih actionable kalau kamu bisa lihat: "Dine-in turun 20%, tapi takeaway naik 5%." Masalahnya spesifik, solusinya juga bisa spesifik.

Apa Selanjutnya

Service mode yang sekarang masih versi pertama. Ke depannya, beberapa hal yang kami eksplorasi:

• Pricing per mode. Beberapa kafe pasang harga berbeda untuk dine-in vs takeaway (karena packaging cost). Fitur ini belum ada tapi ada di radar.
• Mode tambahan. Delivery sebagai mode terpisah dari takeaway — relevan kalau kamu handle delivery sendiri (bukan lewat platform).
• Analytics yang lebih dalam. Tren service mode per jam, per hari, per minggu — supaya kamu bisa predict dan plan lebih akurat.

Semua ini masih eksplorasi. Yang sudah ada dan bisa kamu pakai sekarang: toggle simpel yang memberikan data yang sebelumnya invisible. Dan kadang, data yang simpel tapi konsisten itu lebih berharga dari dashboard yang canggih tapi jarang dilihat.