Different Prices per Location on a Restaurant Menu
The day you open a second branch, a small problem appears that nobody warned you about.
The rent is different. The footfall is different. The customer is different. So the club sandwich cannot reasonably cost the same in both places, and now you have a menu that has to be two menus.
Running different prices per location restaurant menu systems can handle properly is a narrow-sounding requirement that turns out to shape everything about how you maintain a menu at scale.
Most tools solve it badly. This is what the bad version costs you, and what the good version looks like.
Why Would You Price Differently at All?
If you have never run two sites, the question sounds like sharp practice. It is not. The costs genuinely differ.
- A unit in a prime mall and a unit in an industrial area are not the same business.
- Delivery radius. One branch delivers to towers, another to villas twenty minutes away.
- Customer mix. A tourist-facing location and a residential one carry different expectations.
- Local competition. Sometimes the road you are on sets the price, not your spreadsheet.
- Costs across the UAE vary more between emirates than newcomers expect.
Groups that refuse to price locally usually end up either leaving money on the table at the expensive site or pricing themselves out at the cheap one.
There is a fairness question underneath this that is worth answering out loud, because guests do occasionally ask. You are not charging different people different prices for the same thing. You are charging different prices at different businesses that happen to share a name, which is how nearly every multi-site retailer in the country operates.
The Bad Version: Duplicate the Item
This is what most menu tools make you do, and it looks fine for about a month.
You create “Club Sandwich” for branch one and “Club Sandwich” again for branch two, at a different price. Two items. Two photographs. Two descriptions.
Then reality arrives. You change the photograph on one and forget the other. You fix a typo in the description in one place. You add an allergen note to the first and not the second. Six months later the two versions of the same sandwich have quietly become different dishes.
At two branches it is annoying. At six it is a job nobody wants, and it is how a guest ends up reading a description you rewrote a year ago.
The Good Version: One Item, Many Prices
The better model separates two things that people usually confuse. What a dish is, and what a dish costs here.
The dish lives once, in a master catalogue. Name, description, photos, video, allergens, calories, variations and add-ons. One record.
The price does not live on the dish. It lives on the relationship between the dish and the menu it appears in. Assign the item to an outlet, and set the price it carries there.
Change the photograph and every branch updates. Change the price at the mall and only the mall changes. That is the whole mechanic, and once you have used it, duplicating items feels like working with one hand.
What Does That Look Like in Practice?
Say you run three sites.
- Build the club sandwich once, with its photo, description, allergens and its “add bacon” extra
- Assign it to all three outlets
- Set $12 downtown, $10 in the industrial area, $11 at the third site
- Later, swap the photograph. All three update.
- Later still, drop it from one branch entirely. The other two are untouched.
No duplicate records were created at any point, so nothing can drift.
The same applies to everything attached to the dish. Variations, required choices and paid extras are built on the item, so the “add bacon” option exists once and is priced once, rather than being rebuilt three times and slowly diverging.
What Else Should Vary by Branch?
Price is the obvious one. It is rarely the only one.
- A branch without a fryer should not be offering the fried items.
- Opening hours. Including split shifts, which are common here and badly handled by most tools.
- Delivery zones and fees. Each with its own free-delivery threshold and minimum order.
- Payment methods. A dine-in room and a delivery-led site take money differently.
- A tourist-facing branch needs a longer list than a residential one.
- Inclusive or exclusive, with named rates per outlet.
- The WhatsApp number. Orders should reach the kitchen that cooks them.
Each outlet also gets its own QR code and its own analytics, so you can compare sites without exporting anything.
A Trap Worth Knowing About
Because price attaches to the item within a menu, it is technically possible for the same dish to carry different prices in two menus at the same outlet.
That is useful when you mean it. A lunch menu and an à la carte menu can genuinely price the same dish differently, and that is normal practice.
It is a problem when you do not mean it. If a special offers menu and a main menu both carry the same dish at different prices, a guest pays a different amount depending only on which QR code they scanned. Nobody set out to do that. It happens when someone builds a promotional menu and forgets to take it down.
The habit that prevents it is simple. When you build a second menu for an outlet, write down which items appear in both, and check those prices deliberately rather than assuming.
How Do You Set It Up?
- Build each item once in the master catalogue, with everything except the price settled
- Create an outlet for each branch
- Create a menu for each outlet and select which items it carries
- Set the custom price per outlet where it differs from the default
- Set that outlet’s hours, zones, payment methods, languages and WhatsApp number
Do the catalogue properly once and the second, third and fourth branches take an hour each. Do it badly and every new site is a full rebuild.
If you are setting this up with one branch and no immediate plans for a second, still build it this way. It costs nothing extra today and it is the difference between opening site two in an afternoon and spending a week untangling a menu.
Who Should Be Allowed to Change Prices?
This is the question that decides whether the system survives a busy quarter.
Team roles are separate from menu structure for a reason. An outlet manager can run their own branch, an operator can work through incoming orders, and neither can reach group pricing.
The practical effect is that you can hand a site to the person running it without handing over the pricing strategy. Most groups discover they want this in month three, after somebody helpfully corrected a price that was not wrong.
How Do You Handle a Price Rise Across Every Branch?
This is the job that used to take a week, and it is worth walking through because it is the clearest illustration of why the structure matters.
Suppose beef goes up and fifteen dishes need adjusting across four branches. In a duplicated setup that is sixty edits, and the risk is not the effort. It is the three you miss.
With one catalogue, you decide first whether the rise is universal or local. A universal change means editing the default price on fifteen items. A local one means adjusting only the outlets where the pressure is real.
The other half is timing. Because nothing is printed, you can raise prices the morning the new delivery lands rather than at the end of a print cycle, which over a year is not a small number.
Keep a note of what changed and when. Nothing in the tool stops you from adjusting a price on a Friday night and forgetting by Monday which branch you touched.
What About Franchises and Partner Sites?
The same structure covers it, with one difference in emphasis.
A franchise partner usually needs control of their own availability and hours, and no control at all over how the brand describes its food. Because descriptions, photos and allergens live in the shared catalogue and only price and availability are local, that split falls out of the model rather than needing a policy.
You keep brand consistency without micromanaging it, which is generally the thing that breaks down first in multi-site food businesses.
Does This Work Across Emirates?
Yes, and this is where it earns its keep in the UAE specifically.
A group with sites in Dubai, Sharjah and Ajman is running three quite different cost bases and three different customer expectations. One catalogue, three price sets, three delivery zone configurations, and a single place to fix a description.
The QR layer runs on QRHUB, which builds QR code solutions for restaurants across the region.
What Does It Cost?
Per-outlet pricing is not a premium feature here, which is worth saying because in most tools it sits behind an upgrade.
- $29 per month, or $290 for the year, with one outlet included
- Additional outlets added as seats at a fixed monthly rate each, stepping down past ten
- Custom pricing per outlet included on every plan
- 0% commission on every order, permanently
- 30 days free, no credit card
One thing to plan for. A seat is bought before an outlet is created, so an unused seat still bills, and removing an outlet frees the seat without removing it from the subscription. Size the rollout to the branches you are actually opening.
You can look at the current plan and what it includes before you commit.
Prices are current at the time of writing and are billed in USD.
Ask to See It, Not Be Told About It
Almost every vendor will say they support per-branch pricing. Many mean duplication with extra steps.
The test takes two minutes. Ask them to create one item, put it in two outlets, and set two different prices while you watch. Then ask them to change the photograph and show you both outlets updating.
If they duplicate the item to do it, you have your answer, and you now know what maintaining that menu will feel like in a year.
Build the dish once. Price it everywhere.