A restaurant order management system, scoped around the channels

Walk into the back of a small delivery-heavy restaurant at eight in the evening and you will see the actual problem. There is a tablet from one aggregator, a tablet from another, a phone taking calls, and possibly a laptop for the restaurant's own site. Each one chimes. Somebody transcribes from all four onto printed tickets, and the kitchen works from the tickets. The failure rate of that transcription step is the reason anybody starts this project.

So an order management system is not an ordering system. We wrote about the ordering side separately in scoping a restaurant ordering system, which is about menus, receipts and the offline case. This note is about the layer above it: what happens when orders arrive from places you do not control, and the operation has to behave as though they arrived from one.

The aggregator is not the problem, the second screen is

It is fashionable to describe delivery platforms as the enemy of restaurant margin. The commission is real and it is discussed below. But operationally the platform is not what breaks the kitchen. What breaks the kitchen is that there are two of them, then three, and each one has its own screen, its own order states, its own idea of when a prep timer starts, and its own cancellation rules.

A single aggregator with a well-behaved tablet is a workable business. The pain scales with channel count, not with commission rate, and it scales faster than linearly because every added channel adds a reconciliation surface at the end of the day as well as a screen during service.

That framing matters because it changes what you build. If the problem were commission, the answer would be to push customers to your own channel, which is a marketing project. If the problem is channel fragmentation, the answer is a consolidation layer, which is a software project, and the two get confused constantly.

What the system has to own

Strip it back and there are four things that genuinely have to live in one place, and everything else is optional for a first version.

• One queue. Every order from every channel, in arrival order, in one view, with the channel visible but not separating them.
• One state machine. Accepted, in preparation, ready, collected or dispatched, closed. Channel-specific states map into it rather than existing alongside it.
• One menu and availability truth. When an item runs out it stops being orderable everywhere, and that push has to be fast enough to matter during service.
• One record per order that survives the day, carrying the channel, the gross, the commission and the fulfilment route, so the end-of-day numbers are not a reconciliation exercise.

The availability item is the one that gets cut from version one and should not be. Selling something you do not have is the most expensive routine failure in the operation: it produces a cancellation, a refund, a rating hit on a platform you do not control, and a customer who assumes the restaurant is disorganised. It is also the thing a consolidation layer is uniquely able to fix, because it is the only component that knows about all the channels at once.

In Egypt, the receipt is a compliance artefact

If you are building this for an Egyptian operation, the tax receipt is not a formatting decision. The Egyptian Tax Authority publishes the document schemas its eInvoicing and eReceipt system accepts, and restaurants are not covered by the generic case. There is a specific Coffee & Restaurant Receipt document type, alongside Retail, Transportation, General Services and others, each with its own versioned schema. The published SDK type list is the authoritative reference, and it is worth reading before the build rather than after.

Two practical consequences. First, receipt generation belongs in the consolidation layer, not in each channel integration, because you need one compliant document per order regardless of which platform sent it. Second, these schemas version and older versions retire: at the time of writing the Coffee & Restaurant Receipt is on v1.2 with v1.0 marked retired. A system that hardcodes a schema version acquires an expiry date the day it ships, and nobody remembers that when the deprecation lands two years later.

What each channel gives you, and what it keeps

The table is the argument against the usual advice. Pushing every customer to your own channel converts a commission cost into a marketing cost, and the marketing cost is not automatically smaller. It is only smaller if you are good at acquiring demand, and most restaurants are not, which is a skill question rather than a software one. Mostafa Faried's piece on how returns change the arithmetic on Egyptian e-commerce ads makes the same point about a neighbouring category, and the logic transfers. It is in Arabic.

Where the margin actually goes

A consolidation layer does not reduce commission. What it can do is make commission visible per order rather than per monthly statement, which is a smaller claim and a more useful one. Once every order record carries its channel and its fee, you can answer questions the monthly statement cannot: which items are unprofitable on which channel, which hours are only profitable on walk-in, whether the second aggregator is adding orders or just moving them.

That is the honest return on this build. Not saved commission, but the ability to stop guessing about it. The same pattern appears anywhere stock and sales meet, and we went through it in more detail for retail in an inventory system for a retail chain.

What to build first

The first version is the unified queue and the state machine, nothing else. One screen the kitchen works from, every channel on it, one set of states. If the integrations are not available yet, a manual entry form is an acceptable stand-in for a channel, because the value is in the single queue rather than in the automation of any one feed.

Second is availability push, because it is where the largest routine loss is. Third is the order record with channel and fee attached, which unlocks the reporting. Channel integrations come as they come and should be built one at a time, since integrating two systems always costs more than the API docs suggest and doing four in parallel is how this project gets abandoned.

Notifications to the customer are a version-two problem and frequently not a problem at all, since the aggregator already does it on its own channels. We covered the trade in automating WhatsApp notifications and what the billing actually looks like.

The honest limits

Not every aggregator will give you an order feed, and the ones that do may restrict it by contract tier or by market. Before scoping anything, get written confirmation of what integration is available to your account specifically. A consolidation layer that can only consolidate two of your four channels is worth much less than one that covers all four, and this is the assumption that most often turns out to be wrong after the build has started.

Below roughly two channels and modest volume, this is not worth building. One tablet and a printer is a system, and it works. The case appears when the transcription step starts producing errors often enough that somebody can name last week's, which is usually around the third channel.

And it will not fix a kitchen that is over capacity. A consolidation layer makes the queue legible, which sometimes makes it obvious that the queue was never the problem. That is a useful thing to learn and an expensive way to learn it, so count the orders you are actually dropping before you count the screens.