Menu planning across locations gets easier when you build one costed core menu every site runs, allow a small band of controlled local flexibility, and manage the whole thing from a single source of truth. The mistake is letting each location plan its own menu, which destroys your buying leverage and your consistency. Standardize the core, control the flex.
Menu planning for one restaurant is a creative act. Menu planning for 14 is a logistics problem dressed as a creative one. Every item you add multiplies across sourcing, training, costing, and prep at every location. The operators who make it easy are not the most creative. They are the most disciplined about what makes the menu and how it is managed.
Here is the multiplication nobody warns you about. Add one new dish to a single restaurant and you have one item to source, cost, train, and prep. Add it across 14 sites and that one creative decision becomes 14 sourcing relationships, 14 training sessions, 14 costing checks, and 14 prep workflows that all have to land the same way. A menu that would be trivial to manage at one location becomes a logistics avalanche at 14 unless you treat every addition as the system-wide commitment it actually is.
One Costed Core Menu, Everywhere
Start with a core menu that every location runs, and cost every item before it ships. A costed core menu gives you buying leverage, training simplicity, and consistent guest experience in one move. When all 14 of my sites ran the same costed core, I could negotiate volume pricing, train to one standard, and compare locations cleanly because they were selling the same thing.
- Buying leverage, because shared items mean volume on every SKU
- Training simplicity, because one menu means one training program
- Clean comparison, because sites selling the same menu are comparable
- Cost control, because every item is costed before it launches
Costing every item before it ships is the discipline most operators skip, and it is the one that separates a menu that prints money from one that quietly loses it. A dish that looks like a winner on the plate can be a margin sink once you actually price out the protein, the yield loss, and the labor to produce it. Across 14 sites that mistake does not happen once, it happens 14 times a day, every day the item is on the menu. Running the cost first means you never launch a dish you cannot make money on, and you set its price from the margin you need rather than from what felt right. The core menu is not just a list of food. It is a list of food you have already proven you can sell at a profit everywhere.
Allow Local Flex, but Put It in a Box
Rigid identical menus ignore real differences between markets. The answer is controlled flex: a defined band, maybe 10 to 20 percent of the menu, where a location can run local items, within rules. The item still gets costed, still gets a spec, still gets approved. Flexibility without rules is just 14 different restaurants sharing a logo.
The word that does the work here is controlled. Flex is not permission to improvise, it is a defined lane with the same guardrails as the core. A local item still has to be costed to target margin, still has to carry a spec so it executes the same every time it runs, and still has to be approved before it ships. What it gets is room to reflect a real market difference: a regional favorite, a local supplier worth featuring, a seasonal item that only makes sense in one climate. Done this way, the flex band gives your managers genuine local relevance without letting the menu fragment into 14 unmanaged operations. The band is the deal: real autonomy inside it, none outside it.
| Menu element | Core or flex | Control |
|---|---|---|
| Signature items | Core | Identical everywhere |
| Costed and spec'd | Both | Required before launch |
| Local specials | Flex | Within 10-20% band |
| Pricing | Core with local adjust | Approved range |
| Seasonal rotations | Core | Rolled out system-wide |
How to Decide What Earns a Spot on the Core Menu
Not every dish your chefs love belongs on a 14-site core menu. The core has to clear a higher bar, because every item on it multiplies across the whole group. Run each candidate through a gate before it ships, and you keep the core lean enough to actually manage.
- Confirm the item can be costed to hit your target margin at every site, not just the flagship
- Check that the key ingredients can be sourced reliably across all your markets
- Make sure it can be trained to a clear spec so it executes the same everywhere
- Verify the prep fits existing workflows rather than forcing a new station or skill
- If it passes all four, it is core; if it only works in one market, it is a flex candidate
The Mistake That Destroys Leverage and Consistency
The failure I see most is the operator who lets each location plan its own menu in the name of local autonomy. It feels generous and entrepreneurial. It is quietly fatal. The moment every site runs a different menu, you lose your volume on every SKU, so your buying power evaporates and your food cost climbs. You lose your single training program, so onboarding fragments. And you lose the ability to compare sites at all, because they are no longer selling the same thing. What looks like empowering your managers is actually dismantling the three advantages that make a multi-unit group worth running. Standardize the core. Box the flex. That is how you give managers real local relevance without surrendering the leverage that pays for everything.
Manage the Whole Menu From One Source of Truth
The thing that makes multi-location menu planning actually easy is managing it in one place. When recipes, costs, specs, and rollouts live in a single system instead of scattered spreadsheets and binders, a menu change becomes one update that flows to every site. This is exactly the problem an operating system for catering and multi-unit food ops is built to solve: the core menu, the costing, and the controlled flex in one source of truth.
Without that single system, a menu change means emailing 14 managers, hoping they all update, and discovering at the next inventory that three of them did not. With it, you change the recipe once and every location sees the same costed, spec'd item. That is the difference between menu planning as a monthly fire and menu planning as a five-minute update.
The three-sites-did-not-update problem is the one that does the real damage, because it is silent. You send the new recipe, eleven sites adopt it, three keep running the old version, and nobody tells you. For weeks those three sites are selling a different product at a different cost, and you find out only when their food cost looks strange or a guest mentions the dish tastes different at one location. A single source of truth removes the gap between deciding on a change and the change actually being live everywhere, because there is no manual step to skip. The update is the rollout. That collapses both the time menu planning takes and the quiet inconsistency that scattered spreadsheets and email chains guarantee at scale.
See how a single operating system keeps your core menu, costs, and local flex aligned across every location.
See CaterOSYour Menu Planning Checklist
Before your next menu change ships, run it against this list. It keeps the core disciplined and the flex from turning into 14 different restaurants.
- Every core item is costed to target margin before it launches anywhere
- The flex band is defined, usually 10 to 20 percent, and every local item is still costed and spec'd
- Pricing moves stay inside an approved range, not freelanced site by site
- Seasonal and signature changes roll out system-wide, not piecemeal
- All recipes, costs, and specs live in one source of truth
- A menu change is one update that reaches every location, not 14 manual edits
The Bottom Line
Make menu planning easier by standardizing the core, boxing the local flex, and managing it all from one source of truth. The creativity goes into a disciplined core menu, not into 14 sites improvising. Build your costed core this quarter and define the flex band before anyone adds a special. Easy menu planning is not less ambition, it is more structure.