POS With Online Ordering India: 7 Best Practical Checks
Most Indian restaurants already take online orders. Very few take them through their POS. The order arrives on an aggregator tablet, somebody reads it, and types it into the till. A POS with online ordering exists to delete that step. Our restaurant POS software page covers the product.
This guide covers what integration should actually do, the six things to settle per channel, and how to test it.
On this page
What a POS with online ordering should do
The target is simple. An order placed online becomes a kitchen ticket without a human retyping it.
Three things follow from that. The kitchen sees one queue instead of a counter and a tablet. Stock moves for an online order exactly as it does for dine-in. And the sale carries a channel, so margin can be read by channel later.
If any of those three is missing, the integration is partial, and partial integration usually costs more effort than it saves.
The re-keying problem is bigger than it looks
Re-typing an order takes perhaps forty seconds. At thirty delivery orders an evening that is twenty minutes of someone’s attention at the busiest hour.
The cost that matters more is accuracy. A re-keyed order is where modifiers get dropped, which is how a no-onion order reaches a customer with onion.
The third cost is stock. If online orders never touch the POS, the stock ledger is wrong by exactly the volume of the delivery business, and reordering runs on it every morning.
Own channel or aggregator
These are different commercial decisions and the software treats them differently.
An aggregator brings demand and takes commission, often a fifth of the ticket. Your own ordering page takes no commission but brings no demand, so it mainly converts customers who already know you.
Most Indian restaurants need both. The practical point is that a POS with online ordering should ingest aggregator orders and host your own channel, and tag both so they never blur in the reports.
Menus differ by channel, and that is normal
A delivery menu is rarely the dine-in menu. Items that travel badly get dropped, portion sizes change, and prices often rise to absorb commission.
That means the system has to hold more than one menu against one item master, rather than forcing a single price list everywhere.
The six items above need an answer per channel before go-live. The one most often left open is who marks an item unavailable, because during service it has to be a waiter or a cook, not an office login.
Failed syncs are the real test
Any integration works when everything is up. What separates products is what happens when something fails.
An aggregator API can time out. A menu push can be rejected. An order can arrive for an item you marked out of stock a minute ago.
| Failure | What a weak system does | What a good one does |
|---|---|---|
| Order arrives during an outage | Lost silently | Queued and surfaced on reconnection |
| Menu push rejected | Prices drift between channels | Error shown, with the rejected item named |
| Item sold out mid-service | Orders keep arriving | Availability pushed out immediately |
| Duplicate order received | Two kitchen tickets | Deduplicated on the order id |
| Payout does not match sales | Nobody notices | Reconciliation report by channel |
Ask where a failed sync appears and who is expected to look at it. If the answer is a log file, the answer in practice is nobody.
Preparation time and the promise you make
Online ordering adds a promise a dine-in restaurant never makes: a time. Get it wrong and the complaint arrives before the food does.
A POS with online ordering should let the kitchen set preparation time by item or by current load, rather than publishing one optimistic number all evening.
The useful control is being able to raise it during a rush. A restaurant that cannot extend its quoted time at 9pm is choosing between late orders and refusing them.
Who watches the orders
Integration removes typing but not attention. Somebody still has to accept orders, flag an item that has run out, and notice a rider who has not arrived.
Decide before go-live whether that is the counter, the pass or a dedicated person on busy evenings. The most common failure after a good integration is nobody owning the screen.
It is the same discipline as the floor: an alert with no named owner is a fact nobody acts on, which is the point we make about table management too.
Margin by channel is the whole point
A dish earning a comfortable margin in the dining room can lose money on delivery once commission, packaging and the occasional refund are counted.
Without a channel on the sale, that is invisible, and a restaurant can grow revenue while shrinking profit without noticing which channel did it.
The report to ask for is contribution by dish by channel. Many systems offer sales by channel, which is a different and much less useful number. The underlying method is in our menu engineering guide.
Packaging, riders and the costs nobody books
Delivery carries costs that dine-in does not, and they rarely reach the margin calculation.
Packaging is the obvious one and is usually a real per-order cost. Refunds and compensation for late or wrong orders are the second. Where a restaurant runs its own riders, there is a labour cost that belongs against the channel rather than against the kitchen.
A POS that lets packaging be added as a line, even at a nominal rate, gets the margin closer to the truth than one that ignores it.
Seven checks before buying
- Place an online order and watch a kitchen ticket print without anyone typing.
- Confirm the stock movement matches a dine-in order of the same dish.
- Set a delivery price different from the dine-in price on one item.
- Mark an item unavailable from the floor and see it disappear from the channel.
- Force a failed sync and find where the error surfaces.
- Open contribution by dish by channel, not just sales by channel.
- Reconcile one day of aggregator payout against recorded sales.
Check one is the reason to buy. Check five is the reason some integrations quietly stop being used after a month.
If the restaurant runs more than one outlet, add the usual question of whether menus and availability are managed centrally, which is what multi-outlet management is for.
One closing note. A POS with online ordering is worth buying only if somebody will own the screen every evening. The integration removes the typing; it does not remove the job.
Frequently asked questions
What does a POS with online ordering actually do?
It turns an order placed on your site or an aggregator into a kitchen ticket without anyone retyping it. Stock moves as it would for a dine-in order. And the sale records its channel, so margin can be read by channel afterwards.
Why is re-keying aggregator orders a problem?
Three reasons. It costs about forty seconds an order at the busiest hour. It is where modifiers get dropped. And it leaves the stock ledger wrong by the entire volume of the delivery business.
Should the delivery menu match the dine-in menu?
Usually not. Items that travel badly get dropped, portions change and prices often rise to absorb commission. The system should hold more than one menu against a single item master.
What should happen when an integration fails?
Orders arriving during an outage should queue and surface on reconnection. A rejected menu push should name the item. Duplicates should be deduplicated on the order id. And a human should see the error without reading a log file.
How do I know if delivery is profitable?
Ask for contribution by dish by channel, not sales by channel. Then add packaging, refunds and rider cost where you run your own. Commission alone can take a fifth of the ticket.
Sources, method and author
Method. Operational points reflect restaurant POS and online ordering deployments Clonet Technologies runs in India. Commission, packaging and payout terms are described in general terms, because they vary by aggregator and by contract and a single quoted figure would mislead. GST treatment was checked against the GST portal in September 2026.
- Goods and Services Tax portal — restaurant supply treatment on delivery orders
- FSSAI — licensing and labelling for food delivery
- National Restaurant Association of India — industry body for Indian food services
- Department of Consumer Affairs — consumer rules on charges and refunds
Disclosure. Clonet Technologies Pvt Ltd builds and sells Clotouch POS. Linked product pages are our own. We do not take a position on which aggregator a restaurant should use.
Author. Aman Raj. Rewritten 30 September 2026 for Clonet Technologies Pvt Ltd, Bengaluru.
