Why We Built Service Modes — and Why Your Cafe Needs to Separate Dine-In and Takeaway

One Simple Question That Changes Everything

"For here or to go?"

This question is asked at every cafe, every day, dozens of times. And the answer changes a lot — packaging, sometimes pricing (some cafes charge differently for dine-in vs takeaway), presentation style, even kitchen priority.

But in most POS systems, this information disappears. An order comes in as "1 Fried Rice, 1 Iced Latte" — with no record of whether it's eating in or taking away. The result?

• The kitchen doesn't know whether to plate (dine-in) or package (takeaway)
• Reports can't break down what percentage of revenue comes from each mode
• You don't have data for important decisions: "Should we invest in better seating or better packaging?"

What Service Mode Does

Service mode in CrescendPOS is a simple toggle at the start of each transaction: Dine-In or Takeaway. One tap, before the cashier starts entering items.

From that single tap, several things happen automatically:

• Receipts show the service mode. The kitchen sees "DINE-IN" or "TAKEAWAY" on the receipt — they immediately know how to serve.
• Separate reporting. In analytics, you can filter sales by service mode. See the revenue breakdown: how much from dine-in, how much from takeaway.
• Data for decisions. After a month, you know: "60% of our revenue is from takeaway" — and that changes how you think about investment (packaging over furniture).

Why This Isn't as Simple as It Looks

"It's just a dine-in/takeaway toggle, how hard can it be?" Technically, it's straightforward. What's difficult are the design decisions behind it.

Mandatory or Optional?

First question: should the cashier be required to select a service mode for every transaction, or can they skip it?

If mandatory: every transaction has complete data. But if your cafe is a pure counter-service model where 95% is dine-in, that extra tap on every transaction is annoying — it adds time during rush hour.

If optional: cashiers who forget or can't be bothered will skip, and your data becomes unreliable.

Our solution: owners can toggle the feature on or off per cafe. A cafe that's purely dine-in? Turn it off — no toggle needed. A cafe with mixed dine-in and takeaway? Turn it on, and set a default mode (e.g., default "Dine-In," switch only when takeaway).

One Toggle or Many Options?

We initially considered more than two options: Dine-In, Takeaway, Delivery, Drive-Through. But for V1, we pulled back to just two: Dine-In and Pickup/Takeaway.

Why? Because most small cafes in Indonesia operate in these two modes. Delivery usually goes through third-party platforms (food delivery apps) that have their own systems. Drive-through barely exists for small cafes.

Our principle: build for needs that exist, not for hypothetical scenarios. When demand for additional modes is clear, we'll add them. But not now.

Where Does the Toggle Go?

Toggle placement in the UI matters. We put it at the start of the transaction flow — before the cashier begins entering items. Why?

• Cashiers typically ask "eating here or taking away?" at the start of the interaction, not at the end. The UI should match the natural conversation flow.
• If placed at the end (before payment), cashiers often forget because they're already focused on the payment step.
• At the start, the information is immediately available for printed receipts — including kitchen receipts that print as items are entered.

What We Learned

Some insights from building this feature:

Missing data is as dangerous as wrong data. Before service modes existed, many cafe owners "felt" that most revenue came from dine-in — but after tracking, takeaway was often 40-50%. Feelings are unreliable; data is reliable.

Small features can have big business impact. A single toggle that tells you "weekends are mostly takeaway, weekdays are mostly dine-in" can change your staffing strategy (more people in the packaging area vs on the floor) and menu strategy (items that travel well for takeaway vs items that need beautiful plating for dine-in).

Simplicity is a feature. We could have built a super-advanced service mode — with different pricing per mode, automatic packaging costs, different kitchen workflows. But for V1, one simple toggle already solves 80% of the problem. Advanced features can come later when demand is clear.

Why This Matters for Your Cafe

If your cafe has a mix of dine-in and takeaway (and most cafes do), separating data between these two modes gives you visibility that was previously invisible:

• Staffing decisions. If 70% of afternoon traffic is takeaway, you need packaging speed more than floor service.
• Menu decisions. Items frequently ordered as takeaway but that don't travel well (ice cream that melts, rice that gets soggy) = candidates for improvement or replacement.
• Layout decisions. Do you need a larger pickup area? Or more seats? Service mode data answers this.
• Revenue understanding. "This month's revenue is down 10%" becomes more actionable when you can see: "Dine-in dropped 20%, but takeaway grew 5%." The problem is specific, so the solution can be specific too.

What's Next

The current service mode is still version one. Going forward, some things we're exploring:

• Per-mode pricing. Some cafes charge different prices for dine-in vs takeaway (due to packaging costs). This feature doesn't exist yet but is on our radar.
• Additional modes. Delivery as a separate mode from takeaway — relevant if you handle your own delivery (not through platforms).
• Deeper analytics. Service mode trends by hour, day, and week — so you can predict and plan more accurately.

These are all explorations without firm timelines. What's available now: a simple toggle that surfaces data that was previously invisible. And sometimes, simple but consistent data is more valuable than a fancy dashboard that nobody looks at.