Running a cloud kitchen: several brands, one kitchen, one POS

A cloud kitchen strips a restaurant down to its economics. There is no atmosphere, no upselling server, no dine-in margin cushioning the delivery commission. What is left is prep time, channel mix, commission and food cost — and all four have to be right.

The multi-brand problem

Most cloud kitchens run several virtual brands from one kitchen. Three brands across six platforms is eighteen listings, and it creates a specific set of requirements.

You need per-brand reporting. Revenue, food cost and contribution per brand, not for the kitchen as a whole. Without it, a losing brand is subsidised invisibly by a winning one, sometimes for a year.

You need shared inventory with per-brand consumption. One stock of chicken; three brands drawing from it. Your system must deduct correctly so each brand's food cost is real.

You need per-brand prep times. Platforms hold you to the preparation time you promise. Different brands with different dishes should not share one number.

Be aware that, per our August 2026 audit, native multi-brand management is present in Foodics, NCR and Oracle, and isnot available in Wameed, Rewaa, Marn, Revel, Geidea, Odoo, Sapaad or Hala. If you need formal multi-brand handling with separate accounts and consolidated reporting, that is a real constraint and worth checking before you commit.

A practical workaround many operators use is one account with brands as categories or channels — which gives per-brand reporting without separate accounts. It works well up to a point; it is not the same thing.

Channel mix is your whole P&L

Track contribution per platform, not just revenue. A platform with 30% commission and heavy funded promotions can produce a lot of revenue and very little money. Seedelivery commission maths.

The monthly question is simple:which platform gave me the most contribution per order, and which gave me the least? If one is consistently negative, reduce its menu to the dishes that survive, or leave it.

Prep time is the rating

Platform ratings are driven heavily by preparation-time accuracy. Promising 20 minutes and delivering in 35 damages you twice — the customer waits, and the algorithm demotes you.

Two practical rules:

• Set prep times per dish, and let the system sum them for the order rather than using a single kitchen-wide figure.
• Raise prep times during your peak. A dynamic number that reflects reality beats an optimistic constant.

Integration is not optional here

A dine-in restaurant can survive re-keying delivery orders. A cloud kitchen cannot: delivery is 100% of the volume.

Integration means orders arrive in the POS and on the kitchen display without a person typing them. Wameed integrates with ten platforms — Jahez, HungerStation, Keeta, Talabat, Noon Food, Mrsool, Ninja, The Chefz, ToYou and Carriage. See theaggregator guide.

Kitchen display, not printers

With multiple brands arriving simultaneously, paper tickets stop working quickly. A KDS with station routing and brand tagging is close to essential. See theKDS guide.

Note the outage caveat: Wameed's KDS needs the local server. Keep a printer as the fallback and rehearse the switch.

Packaging is a real line

Cloud kitchens spend meaningfully on packaging, and it is easy to under-track because it is not food. Set it up as a stock item, deduct it per order, and it appears in your cost properly rather than as a mystery in the monthly accounts.

The weekly review

1. Contribution per brand
2. Contribution per platform
3. Prep-time accuracy and rating movement
4. Cancelled and refunded orders, by cause
5. Packaging cost per order
6. Food cost variance — theoretical versus actual. Seefood cost control

The failure mode

The most common way a cloud kitchen fails is launching too many brands too quickly. Each brand needs a menu that works for delivery, accurate prep times, its own photography and its own reviews. Three brands done properly beat eight done badly, and the eight consume all the attention that would have made the three work.