Look at the counter of almost any Malaysian restaurant doing delivery. There is the POS, and next to it a tablet for GrabFood. Maybe another one beside that. Each one beeps. Each one needs somebody to notice it.
During a quiet afternoon this is merely untidy. During a Friday dinner rush it is where orders get missed, food gets made twice, and someone is standing at a screen typing an order that already exists in digital form two feet away.
This post is about removing that tablet, and more importantly about removing the double entry behind it.
The real problem is not the tablet
The tablet is the visible symptom. The actual cost is that your delivery orders live in a separate system from everything else, which creates four distinct problems.
Someone has to watch it. An order arrives, the tablet chimes, and if nobody hears it during a rush the clock is already running on your prep time before anyone has started.
Someone has to retype it. Reading an order off one screen and keying it into another is the single most error-prone thing that happens in a busy kitchen. Wrong item, wrong quantity, missed modifier, and you find out when the customer complains.
Your numbers are split. Dine-in sales are in the POS. Delivery sales are in the platform dashboard. Working out what you actually sold today means opening two systems and adding them together by hand.
Your stock is wrong. If delivery orders never touch your POS, they never reduce your stock counts. Every delivery order makes your inventory figures less accurate than they were.
The tablet costs you counter space. The double entry costs you accuracy, and accuracy is what you were buying a POS for in the first place.
What integration actually means
When GrabFood is properly connected to your POS, the flow changes shape entirely:
- The order arrives in your POS directly. Not on a separate screen. In the same place as every other order.
- It prints to the kitchen automatically. Same printer, same format, same workflow as a dine-in order. Your kitchen does not need to know or care where it came from.
- Nobody retypes anything. The items, quantities and notes arrive as data, not as text on a screen for a human to copy.
- It counts in your sales figures. One set of numbers at the end of the day, covering every channel.
- Stock moves. A delivery sale reduces your counts exactly like a counter sale.
The tablet becomes unnecessary rather than merely tidied away, because nothing needs to happen on it.
The part people underestimate: menu sync
Here is what nobody tells you before you set this up. The hard part is not receiving orders. It is keeping your menu consistent between two systems.
Your POS has items with names, prices and modifiers. The platform has its own menu with its own names, its own prices, and its own idea of what a modifier is. If those two drift apart, orders arrive that your POS cannot match to anything it knows about.
The failure mode is subtle and worth understanding. An item renamed on one side but not the other does not throw an obvious error. It quietly fails to match, and you find out through a mismatched report at month end rather than at the moment it broke.
Two practical consequences:
- Ask specifically how menu sync works before you commit. One-directional, two-directional, manual, automatic? What happens when you change a price?
- Decide which system is the master. The most reliable setups have one authoritative menu that pushes to the other, rather than two menus maintained in parallel by hand.
Delivery prices are usually not your shop prices
A practical point that catches people out. Platform commission is significant, and most restaurants price delivery items higher to absorb some of it.
That is a legitimate business decision, but it means your integration has to support different prices for the same item depending on channel. A system that assumes one item has one price will force you to choose between losing margin on every delivery order and creating duplicate items, and duplicate items make your reporting misleading in a way that is hard to unpick later.
Ask about channel pricing before you assume it is handled.
What to check before you commit
A short list of questions worth asking any vendor claiming delivery integration:
- Do orders arrive automatically, or does somebody accept them on another device first?
- Do they print to the kitchen without manual intervention?
- How does menu sync work, and which side is authoritative?
- Can I set different prices per channel?
- What happens to an order if the internet drops for two minutes?
- Do delivery sales appear in the same reports as everything else, separated by channel?
- What happens when the platform changes something on their end?
That last one matters more than it appears. Platform APIs change, and the answer you want is that your vendor handles it, not that you find out through broken orders on a Saturday.
Is it worth it for you?
Honestly, it depends on volume. Some rough guidance:
If delivery is a handful of orders a day, the tablet is annoying but survivable, and integration is a convenience rather than a necessity. If delivery is a meaningful share of your revenue, say more than about a fifth, then the double entry is costing you real money in errors and staff time, and your reporting is materially wrong because of the split.
The tipping point in practice is usually when you first miss an order during a rush, or when you first realise your stock figures have been drifting for months because delivery never touched them.
Frequently asked questions
Does this work with foodpanda too?
Platform support varies by POS vendor, so ask specifically about each platform you use rather than assuming that support for one means support for all. If you run more than one platform, that is a question to settle before you buy.
Do I still need the platform's merchant app?
Usually yes, for account management, promotions and support. What changes is that you are no longer using it to take orders during service, which is the part that was costing you.
What happens if my internet goes down?
Orders that cannot reach you will queue on the platform side. What matters is what your POS does when the connection returns, and whether it catches up cleanly. Ask this question directly.
Will this reduce the commission I pay?
No. Commission is between you and the platform, and integration does not change it. What it reduces is the staff time and error rate on your side.
Can I see delivery and dine-in separately in reports?
You should be able to, and you want to. The whole point is one set of numbers that can still be broken down by channel, since your margin on delivery is genuinely different.
The bottom line
Removing the second tablet is the visible win. The real one is that delivery orders stop being a parallel universe with their own numbers, their own errors and their own invisible effect on your stock.
If delivery matters to your business, the questions to ask are about menu sync and channel pricing rather than about whether orders arrive, because those are the parts that quietly go wrong months after setup.
Shiok POS handles GrabFood orders directly into the till with automatic kitchen printing. If you want to see how it would work with your menu, get in touch, or look at what is included in our Growth plan.
See Shiok POS in action
An all-in-one POS built for Malaysian retail and F&B, with local support and hardware that is ready to trade on day one.
Get a Demo