Orders from delivery apps

That is what this is. Your own ordering page, the counter, the tables and the food delivery platforms all end up in one order list, one kitchen screen and one set of figures. Restaurant delivery software that only covers one of those leaves somebody re-typing orders at noon, which is exactly when nobody has a spare hand.

Talabat, foodpanda, Deliveroo, Careem Food, Keeta, GrabFood and noon Food. Six of them connect properly, so orders arrive on their own and your answers go back. noon Food publishes no way in, so its orders come through the manual door on the same page.

Yes. That is the whole point of it. An order from an app becomes an ordinary order in Get Menu: it gets your next order number, it sits on the orders board with everything else, and it shows on the kitchen screen with your own tickets. The line on the board names the app and says the money was paid to the app.

No. Connecting the apps and answering their orders works from the admin on any plan. The kitchen screen is part of the POS add-on, so if you want your cooks to accept and refuse from the wall screen you need that; otherwise answer from the Delivery apps page in the admin.

We charge nothing extra for it. The apps charge their own commission and their own fees, and that is a matter between you and them. We never take a share of an app order and we never change the numbers the app sends.

Whatever you agreed with them. We do not see it and we do not deduct it. The total we record against an app order is the total the app told us, to the fils.

Settings, then 'Delivery & dine-in', then 'Delivery apps'. Each app has its own card with its own form: your store id, the keys the app issued you, how many minutes you need to prepare, and whether orders are accepted on arrival. Press Connect, then paste the address shown on the card into the app's own portal so it knows where to send orders.

It is the code that identifies your branch inside that app's system, and you get it from the app, not from us. Deliveroo calls it a site id, Talabat and foodpanda call it a vendor code, Careem calls it a branch id, Keeta calls it a store id, GrabFood calls it a merchant id. If you cannot find it, ask your account manager at the app.

No. Every box on the form is something the app hands you, and you paste it in. The only step outside Get Menu is telling the app where to send orders, which is copying one address from our page into a field in their portal.

That depends on the app, not on us. Deliveroo issues its keys through its own developer portal, so you can be running the same day. Talabat and foodpanda hand out access to a point of sale company after a partner request and paperwork, and Careem and Keeta both want an agreement signed and a live test passed first. The card for each app says where it stands.

Yes, where the app offers a test account. Tick 'Sandbox / staging' when you connect and use the test credentials the app gave you. Everything behaves the same way; the orders are just not real.

We check that it really came from the app, record it as an order with your next order number, and put it on the orders board and the kitchen screen. If 'Accept orders on arrival' is on, we say yes to the app in the same breath and tell it your prepare time. If it is off, the order sits waiting for somebody to tap Accept.

In two places, and both of them tell the app: the 'Orders from the apps' panel on the Delivery apps page, and the kitchen screen, where the ticket shows 'Accept the order' and 'Refuse' instead of the usual Ready button. Moving an app order along on the ordinary orders board changes your side only and does not speak to the app.

Yes. Tick 'Accept orders on arrival' on that app's card. We then answer the app the moment the order lands, which matters because most apps give you only a couple of minutes before they treat silence as a refusal. Set 'Minutes to prepare' honestly, because that is the number we promise them.

It is the time we tell the app you need once an order is accepted, and it is what the app uses to decide when to send a rider. Anything from 1 to 180 minutes; it starts at 20. Some apps clamp it to their own limits, which is their choice, not a fault.

Four: kitchen too busy, something has run out, closing early, or other. We pass the reason to the app in its own wording, and the order is cancelled on your board at the same moment.

Where the app accepts a ready signal, yes, and it is sent the moment the last dish is ticked off on the kitchen screen. Talabat, foodpanda, Careem, Keeta and GrabFood all take one. Deliveroo does not publish one at all, because it times its riders from its own model, so nothing is sent and nothing is broken.

Once an order is marked ready, a 'Picked up' button appears beside it. For Talabat, foodpanda and Keeta that is sent to the app. Deliveroo, Careem and GrabFood have their own rider apps reporting the collection, so there is nothing for us to send and the message will say so.

Your side is still correct: an accepted order is accepted, a refused order is cancelled. The message on screen says the app did not take it and asks you to tell them by hand on their tablet. The card also shows the last error, and the reason sits in the 'What the apps said' panel.

Yes. 'What the apps said' at the bottom of the Delivery apps page lists the last thirty messages in and out, with the time, the app, the direction and what happened, and anything that failed in red. It is the first place to look when an order you expected never appeared.

Press 'Pause (refuse orders)' on that app's card and we refuse everything it sends until you switch it back on. Be clear about what this is: it stops orders reaching your kitchen, it does not close your shop inside the app, so the app may keep trying and customers may keep seeing you open. To go dark properly, close the store in the app's own tablet or portal as well.

Pause is for the rest of the shift: the connection and all your settings stay, we simply refuse what arrives, and one press brings it back. Disconnect is for good: we stop recognising that store, and orders from it are turned away. Connecting again means filling the form in again.

Yes, through the manual door. noon Food publishes nothing to connect to, so somebody types the order from the noon tablet into the form on the Delivery apps page and it goes to the board and the kitchen like any other. Accepting, refusing and marking it ready still happen on noon's own tablet, because there is nowhere for us to send that.

Use 'The manual door' on the Delivery apps page. Pick the app, type its order code, the customer, the lines with prices, the delivery fee and any discount, and press 'Send to the kitchen'. A hand-typed order is treated as already accepted, because you accepted it on their tablet.

Only for lines you have matched to one of your dishes, and only for dishes you are counting. The count comes down when the order is recorded. If the count would go below zero we leave it alone rather than refuse the order, because the app has already sold and charged for it and refusing would help nobody.

Because that product id has not been matched to one of your dishes yet. An unmatched line is kept exactly as the app wrote it, so the kitchen still gets the right thing; it just carries their words and moves no stock. Match it under 'Which dish is which' and the next order reads properly.

Yes, for dishes you have matched, and for the apps that accept it. Switching a dish off on your Menu page, or marking it sold out on the POS stock screen, sends the change out to every connected app that can take one. Whether each app accepted it is written into 'What the apps said'.

No. Your menu and your prices inside a delivery app stay in that app's own portal, where you set them today. What we send them is availability, so a dish that has run out stops selling there too.

Yes. They are ordinary orders, so they appear on the orders board, in the orders CSV export and in your monthly figures alongside everything else. That is the point of doing your food delivery management in one place: the day's real total is the day's real total, whichever app it came through. On the board the line names the app; in the export the Notes column carries the app's name and its own order code, so you can pick them out.

No, deliberately. The app took the money from the customer and owes it to you, so nothing was handed over at your counter. The shift figures and the closing report count what the POS actually took, and an app order never touches them. That is what keeps your drawer count honest.

No. The app owns that conversation and sends its own updates, and the number an app passes on is usually a masked one anyway. We send nothing to the customer for an app order and nothing to your managers group either; the order simply appears on the board.

As a rule, no. Stamps are counted against a customer we know, and an app order does not create one, because the apps do not hand over the customer's real number. Orders placed on your own ordering page do count, which is one more reason to keep pushing your own link.

No. It appears on the kitchen screen, which is where cooks accept it, tick lines off and mark it ready. Printing happens as part of a sale rung up at the counter, and an app order is not one.

Nothing bad. We recognise it as one we already have and answer the app again without creating a second order. Apps retry when they are unsure their message arrived, so this happens more often than you would think.

The app tells us and we cancel it on your board with the app's reason written against it, unless it has already gone out as delivered. It appears in 'What the apps said' too, so there is a record of who cancelled and when.

The owner or a manager. Every connect, pause, disconnect, hand-typed order and dish match is recorded with who did it and when, which matters on a screen that decides whether orders can reach your kitchen at all.

GrabFood works in South-East Asia only: Singapore, Malaysia, Thailand, Vietnam, the Philippines, Indonesia, Cambodia and Myanmar. If you are in the Gulf, the cards that matter to you are Talabat, Deliveroo, Careem, noon and Keeta.

All of them. The page shows one card per app, so one store id per app, and each keeps its own switches, its own prepare time and its own status. A busy kitchen usually runs three or four.

Yes, and this is the honest case for it. An app brings you customers you would not otherwise reach, and keeps them: you get an order, not a customer. An order on your own ordering page gives you the number, the follow-up, the loyalty stamp and the right to message them again. Most restaurants run both and slowly move their regulars across.

Open the Delivery apps page. The app's card shows when the last order came in and any error it returned; 'Orders from the apps' lists the last forty with their state; and 'What the apps said' shows the last thirty messages in and out. If nothing at all is listed, the address in the app's portal is usually the culprit, or the connection is paused.