Change it once. Correct at every store by dinner. That is Zayos multi location.
Multi location ordering software should hold one master menu that every store inherits, with deliberate per store overrides for price, hours, delivery radius and stock. Staff are pinned to their own locations. Reporting ranks stores instead of summing them. Zayos bills per location, $499 to $699 monthly.
What actually breaks as you add stores?
The problems arrive in a predictable order, and each one is a software structure problem wearing a staffing problem as a disguise.
What breaks
Menu drift starts. Somebody updates a price at one store and forgets the other, and within a quarter you are running two menus that were meant to be one.
What you need
One master menu with deliberate, visible per store overrides. Never two copies.
What breaks
Hours and holidays. One store closes for a holiday, the others do not, and orders keep arriving at a dark kitchen because hours live in one shared setting.
What you need
Hours, closures, delivery radius and prep times set per location, not per brand.
What breaks
People. Everybody shares a login, nobody knows who changed the price, and a weak store hides inside a healthy group average.
What you need
Staff pinned to their own locations, and reporting that ranks stores against each other instead of summing them.
What should be shared, and what has to be different per store?
Shared: the brand, the logo, the colors, the item names and descriptions, the modifier structure, the checkout rules, the promotions you run across the group, the customer list. Get those out of the per store column and your team stops maintaining the same thing five times.
Per store, and this is the list to test any vendor against:
- Hours, day by day, plus the closures. Every store has its own week, and the exception days are what actually hurt. A holiday closure that has to be entered as a permanent hours change is a system that will be wrong again next year.
- Timezone. Trivial until it is not. A group with a store on the other side of a timezone line will have every report, every scheduled promotion and every day boundary quietly off by an hour unless timezone is a property of the location.
- Delivery radius and fees. A dense urban store and a suburban store cannot share one radius. Set it per store, and keep the map honest, because an over wide radius shows up later as cold food and refunds.
- Stock and the 86 list. Running out of hummus in Pompano must not remove hummus in West Palm. If your 86 button is not location scoped, staff will stop using it, and then your menu is lying to diners at every store.
- Prep time and the rush valve. Ticket times differ by store and by hour. Each location needs its own way to add prep minutes, throttle incoming orders during a rush, and pause without going dark on the whole brand.
Price sits in between. Most groups want one price list and one or two exceptions, which is exactly what an override is for. What you must not accept is a system that answers this by giving each store its own menu, because that is not a feature, it is the drift problem with a nicer name.
Why does menu inheritance decide everything?
Because it decides how much work a change costs, and therefore whether changes happen. In an inheritance model, one menu is the source of truth and each location overrides only the specific fields it needs. Raise a price on the master and every store that has not overridden that field follows immediately. The one store that charges differently keeps its override and is unaffected.
In a copy model, each store owns a full menu of its own. Every change is now a task list with as many rows as you have stores, performed by people during service. Nobody keeps that up. Six months later the group is running five different menus, the marketplace listings are worse, and the answer to a simple question, what does this item cost, depends on who you ask.
There is one demo test for this. Ask the vendor to change a price on one item and show you, on screen, every location that just changed. If they open five tabs, you have a copy model.
Who should be allowed to change what?
Most cross store damage is not theft, it is somebody editing the right item at the wrong store. Shared logins make that invisible, which is the real reason to stop using them: not security theater, but the ability to answer who changed this, and when.
A group needs at least four levels. An owner who sees everything. A manager pinned to their own locations for menu, staff, orders and numbers. Kitchen staff who can work tickets and 86 items but cannot touch price. A finance role that reads payouts and refunds and cannot edit the menu at all. Zayos ships owner, manager, kitchen, finance, marketing and support roles, and a manager can be scoped to specific locations so even their staff roster stops at their own stores.
Ask one more question in the demo: when a scoped manager opens reporting, do they see the group total. If they do, the scoping is cosmetic.
How does Zayos run a group of restaurants?
Each location carries its own hours for every day of the week, its own timezone, its own delivery radius and its own pause switch, and the owner edits all of it without calling support. The 86 grid is location scoped and built for a tablet during a rush: big tap targets, item state visible at a glance, and a default cooldown of 30 minutes so an item comes back automatically instead of staying dark until somebody remembers.
The rush controls are per location too. Add prep minutes, cap orders per hour, or let the store pause itself when it goes over and resume on its own after a set number of minutes. A store in the weeds should be able to slow down without the brand going dark.
On the diner side, a brand with more than one location automatically gets a locations page with a map, search and the nearest store, and a single location brand skips it entirely and goes straight to ordering. Fewer taps is the whole design goal: a diner should reach checkout in three clicks.
Reporting ranks stores rather than summing them. The cross location leaderboard shows revenue, orders, average ticket, refund rate and top item per store, colored against the group average, and it honors scope so a regional manager sees their own stores. Marketplace orders arrive through Otter into the same kitchen tablet as direct orders, per store, so the group is measured one way.
What it costs for a group
Per location, flat, and the rate does not change with the count: Operator $499, Operator plus Marketplace $599, Concierge $699 per location per month, month to month, no setup fee. No percentage of sales, no per order fee charged to the restaurant. The diner pays $0.99 on pickup, $2.99 on delivery, nothing on dine in and 10% on catering, and every location keeps 100% of food revenue and 100% of tips. Full breakdown on the pricing page.
Groups already built on this structure include Naya Grill, live and taking orders across Pompano Beach and West Palm Beach, and Mr. Smoke with 13 locations built and ordering opening at launch. Onboarding runs the same way for one store or thirteen: see how it works.
Questions from operators with more than one store
What is the first thing that breaks when a restaurant opens a second location?
What is menu inheritance, in plain English?
How does a diner end up ordering from the right store?
Should a store manager see the other stores?
How does Zayos price multiple locations?
Can I roll a change out to one store first?
How long does it take to bring a group of locations live?
Find out what your group loses per store.
The free AI report reads your current ordering setup and returns the numbers in about 60 seconds. No card, no call.
Also worth reading: POS integration and integrations.