Menu engineering for multi-unit restaurants: how to build profitable seasonal menus

Many restaurant menus quietly lose money.

Some menu items sell well but make very little profit. Others may actually cost you money every time someone orders them. In one restaurant, this is a small problem. Across 30, 50, or 100 locations, it can become a big loss every month.

Menu engineering helps restaurants understand which menu items make money and which ones do not. But most guides only explain it for one restaurant.

Running menu engineering across many locations is different. One item may sell really well in one area but poorly somewhere else. Seasonal menu launches can also become messy if locations are not properly prepared.

This guide explains how to manage menu engineering across multiple locations, plan seasonal menus without confusion, and roll out menu changes in a way that actually works.

Fast fact: The average restaurant menu has between 65 and 75 items. Most operators would run more profitably with 30 to 40. The hard part is knowing which ones to cut.

Related resources

• How to improve restaurant operations: practical steps for operators working through execution gaps across locations
• Average restaurant food cost benchmarks: current food cost percentage benchmarks by restaurant type to validate your menu pricing
• Brand standards audit guide: how to structure audits that enforce menu and execution consistency across locations
• Restaurant inventory management guide: keeping ingredient costs accurate so your menu engineering inputs are trustworthy
• Menu learning for servers: how to train your FOH team on seasonal menu items and upselling techniques
• Scaling a restaurant group: the operational infrastructure decisions that matter as you grow your location count
• Restaurant corrective action guide: how to close the loop after a menu engineering analysis with trackable action steps
• Restaurant task management: how task assignment and tracking connects to operational compliance across locations‍

What is menu engineering?

Menu engineering is a method for analyzing every item on your menu based on two variables: how often it sells and how much gross profit it generates per sale. You then place each item into one of four categories and take a defined action on that category.

The framework was developed by Michael Kasavana and Donald Smith in 1982. It remains the most practical tool for menu profitability analysis because every item gets a clear action, not just a label. You are not just identifying problems. You are building a decision-making system.

The 4 quadrants of menu engineering

**

Quadrant,Popularity,Profitability,What to Do

Stars,High,High,Protect and prominently feature

Plowhorses,High,Low,Raise price or re-engineer the recipe

Puzzles,Low,High,Reposition / rewrite / or actively upsell

Dogs,Low,Low,Remove or completely redesign

**

Stars are the items your operation depends on. They sell often and generate strong contribution margin. Your job is to protect them. Do not bury them. Do not change the recipe without a full cost and quality test first.

Plowhorses are your crowd favorites that cost you money at scale. Guests love them, which is exactly why you cannot just cut them. Your options are to raise price incrementally, reduce portion size carefully, find a lower-cost ingredient substitute, or bundle them with high-margin add-ons to recover margin.

Puzzles have solid margins but low sales velocity. They are usually priced right but described badly, buried in the wrong section, or never upsold by servers. Before you give up on a Puzzle, test a better description, a different menu position, and targeted verbal upselling by your FOH team.

Dogs have neither popularity nor profitability. Unless a Dog exists for a specific reason (an allergen accommodation, a franchise requirement, a brand identity item), it should come off the menu.

The multi-unit twist on menu engineering

Here is where the standard menu engineering model stops being useful.

The four-quadrant framework works when you have one menu, one kitchen, and one customer base. Across a multi-unit portfolio, the same item performs completely differently at different locations. If you do your analysis on brand-wide averages, you will make decisions that help some locations while actively hurting others.

The same item performs differently at each location

A shrimp dish might be a Star at your coastal markets and a Dog at your Midwest suburban locations. A hearty pasta bowl might move 45 units per day at a cold-weather location in January and 12 units at a warm-weather market during the same period. Brand-wide averages wash that signal out entirely.

Here is a simple example of what brand-wide averaging hides:

**

Location, Shrimp tacos daily units, Classification

Location A (coastal), 38, Star

Location B (suburban), 8, Puzzle

Location C (secondary market), 4, Dog

Brand average, 16.7, Puzzle (misleading)

**

Using the brand average, you treat the shrimp taco as a borderline Puzzle. At Location A it is a clear Star. At Locations B and C it is a Dog. A brand-average decision misleads all three markets.

Regional preferences shift your data more than you think

Guest preferences vary by geography, demographics, income levels, and local competition. Urban locations often support higher price points on premium ingredients. Suburban and secondary markets tend to favor value and portion size. A solid restaurant menu engineering analysis has to account for this. Otherwise you are optimizing for a fictional average customer who does not actually exist at any of your real locations.

Some items must stay regardless of quadrant

Brand-standard items are items required by corporate policy or franchise agreements. Some of them are Dogs at specific locations. Some are Plowhorses brand-wide. But removing them is not your decision. Multi-unit menu engineering has to work around these non-negotiables. The analysis still tells you which brand-standard items need the most attention on pricing, portioning, or bundling to recover as much margin as possible.

The core-and-flex model for brand consistency

Most multi-unit operators land on a core-and-flex model. The core menu stays consistent across all locations and covers brand-standard items and your top national performers. The flex portion lets regional managers add or swap a defined number of items based on local performance data and regional preference patterns.

Xenia's Brand Standards Compliance capability supports this directly. You can assign specific checklists, SOPs, and verification requirements to locations based on region, format, or location attributes. 

Core standards get enforced everywhere. Regional variation is documented, tracked, and visible to district managers in real time. You can read more about how this fits into a broader multi-location operations execution approach in our pillar guide.

How to run a menu engineering analysis across multiple locations

This is the step most operators do wrong. They pull a brand-wide sales report, calculate averages, and treat the output as reality. That gives you clean-looking data that leads to decisions that hurt specific locations.

Here is the correct process for multi-unit restaurant menu engineering.

Step 1: Pull 90-day sales mix and recipe cost per item, per location

Ninety days smooths out weekly variation while staying recent enough to reflect your current cost reality. You need unit sales by item by location. Not brand totals. Not regional summaries. Location by location.

You also need a current recipe cost for each item that reflects actual ingredient costs today, not a standard recipe sheet that was written two years ago and never updated.

Step 2: Calculate contribution margin per item per location

Contribution margin is selling price minus the cost of ingredients to make that item. This is not the same as food cost percentage, and the distinction matters.

A $6 appetizer at a 30% food cost contributes $4.20. A $20 entree at a 40% food cost contributes $12.00. Menu engineering runs on absolute dollars, not percentages. Optimizing for food cost percentage alone can lead you to promote low-dollar-contribution items over high-dollar-contribution ones.

**

Item, Price, Ingredient cost, Contribution margin

Classic Burger, $12.00, $4.20, $7.80

Grilled Salmon, $22.00, $8.80, $13.20

Side Salad, $7.00, $1.40, $5.60

Loaded Fries, $9.00, $3.60, $5.40

**

Step 3: Score popularity and profitability against location averages, not brand averages

For each location, calculate that location's average contribution margin per item and average sales velocity. An item is "high profitability" at a location if its contribution margin exceeds that location's average. An item is "high popularity" if it sells at or above that location's average velocity.

This gives you a quadrant classification that reflects actual performance at that specific location. Not a diluted network number that misrepresents every individual market.

Step 4: Classify per location first, then roll up brand-wide

Run the quadrant analysis location by location first. Then build a brand-wide summary showing how each item is classified across the portfolio. A simple frequency count tells you a lot fast:

**

Item, Stars (locations), Plowhorses, Puzzles, Dogs

Classic Burger, 18, 4, 2, 1

Shrimp Tacos, 5, 3, 4, 13

Chocolate Cake, 20, 2, 1, 2

**

From this view, the Classic Burger is a near-universal Star. Protect it everywhere. Shrimp Tacos are Dogs at 13 locations and need a hard strategic decision. Chocolate Cake is a Star across almost the entire portfolio and should be prominently featured on every menu.

Step 5: Build a quadrant-by-quadrant action plan

Each category needs a different response. Build your action plan by category type, not item by item. This keeps the process repeatable and prevents one-off decisions that are impossible to track at scale.

For this analysis to produce reliable results, your recipe cost data has to be accurate across locations. Ingredient costs vary by supplier, region, and season. 

Xenia's Inventory Management capability helps keep real-time visibility on what items actually cost across locations so your menu engineering inputs reflect operational reality rather than theoretical standards from a spreadsheet nobody updates. This also connects to how you manage restaurant inventory management at the location level.

Seasonal menu planning: a multi-unit playbook

Seasonal menus give guests a reason to come back. Limited-time offers often carry higher perceived value than core items, which gives you real pricing power. But for multi-unit operators, seasonal menus are also operational risk. 

A poorly planned LTO across 80 locations means 80 kitchens short on ingredients, 80 teams executing a new prep they were not properly trained on, and 80 simultaneous chances for a guest experience that falls short of what marketing promised.

Here is how to plan seasonal menus without that risk.

The 4-cycle seasonal calendar

Most multi-unit restaurant groups plan around four seasonal windows:

**

Season, Months, Typical LTO window

Spring, March to May, 8 to 10 weeks

Summer, June to August, 8 to 12 weeks

Fall, September to November, 8 to 10 weeks

Winter and holiday, December to February, 10 to 14 weeks

**

Each cycle needs a defined sunset date established before you launch. An LTO that overstays its window cannibalizes your core menu mix and confuses guests when it eventually comes off.

Lead time math: 60 days is the minimum

Most multi-unit operators underestimate the time between "great idea for an LTO" and "this item is ready to execute consistently at every location." For fresh or specialty ingredients, 60 days is the floor. For anything involving supply chain negotiation or specialty equipment, it is closer to 90.

Here is what that lead time covers:

**

Days,Activity

1 to 10,Concept finalization / cost modeling / supplier sourcing

11 to 20,Recipe standardization and food cost verification

21 to 35,Pilot in 3 to 5 locations

36 to 45,Pilot review / adjustments / training material build

46 to 55,SOP finalization / supply chain lock / team training

56 to 60,Pre-launch verification across pilot locations

Day 61,Brand-wide rollout

**

Start the clock too late and one of two things happens. You rush the pilot and discover problems after brand-wide launch. Or you skip the pilot entirely and find out which locations cannot execute the item while guests are already ordering it.

Pilot in 3 to 5 locations before brand-wide

Pick pilot locations that represent your range of formats: high-volume urban, mid-volume suburban, lower-volume secondary market. If the item cannot be executed consistently at all three types, you have a problem to solve before you commit to a brand-wide launch date.

What you are testing in a pilot:

• Kitchen execution time and impact on ticket speed for the rest of the menu
• Ingredient waste and shrinkage rate against your modeled food cost
• Staff confidence with the new prep steps
• Guest response rate and whether guests reorder it in a follow-up visit
• Actual food cost versus the cost you modeled before launch

Sunset criteria: define them before launch, not after

An LTO that does not hit your minimum daily sales velocity threshold in its first two weeks needs an early evaluation. If it consistently exceeds velocity targets through week six, assess whether it should graduate to the core menu permanently. Define both numbers before you launch so the decision is clean and data-driven, not emotional.

For seasonal menu rollouts, Xenia's Brand Standards Compliance and Multi-Unit Operations tools address the execution consistency problem directly. You build a seasonal launch checklist with mandatory photo verification steps. 

Each location confirms ingredient stock is in place, menu displays are updated, and staff have completed prep training before the item goes live to guests. District and regional managers see in real time which locations are launch-ready and which ones need follow-up before the LTO window opens.

This is exactly the gap a real operations execution system closes: the distance between a good plan on paper and consistent execution across every location.

Menu engineering KPIs to track

Menu engineering is not a one-time project. Your best items shift as ingredient costs change, as competitors adjust their menus, and as your guest mix evolves. These are the metrics to track on a recurring basis.

Contribution margin per item. The core metric of menu profitability. Track it monthly per item per location. Flag any item where contribution margin drops more than 10% month over month. That kind of drop almost always signals ingredient cost drift or portion creep, and both are fixable if you catch them early.

Menu mix percentage. What share of total item sales does each item account for? A Puzzle with 0.3% of your mix has minimal absolute impact. A Plowhorse at 15% of your mix is costing you real money at scale. Menu mix shows you where your volume concentrates.

Item velocity. Units sold per day per location. This is your popularity input for the quadrant analysis. Track it separately from menu mix so a price increase does not make an item appear less popular when it is actually still selling at the same rate.

Cross-location variance. For any item classified as a Star brand-wide, look at velocity variance across locations. High variance points to two causes: genuine regional preference differences (useful information for your flex menu model) or execution gaps at underperforming locations (which need to be fixed, not accepted).

New item ramp curve. When you launch an LTO, track its velocity day by day for the first 30 days. Most LTOs peak in week one from novelty energy, then settle into their sustainable rate by weeks three and four. The 30-day number is what you use for quadrant classification. The week-one spike is not your steady-state performance.

**

KPI,Review Frequency,Action Trigger

Contribution margin per item,Monthly,Drop of more than 10% month over month

Menu mix percentage,Monthly,Shift of more than 2 percentage points

Item velocity by location,Weekly,Sustained drop below location average for 3 weeks

Cross-location variance,Quarterly,High variance on brand-wide Stars

LTO ramp curve,Daily for first 30 days,Failure to reach velocity threshold by day 14

**

Common menu engineering mistakes multi-unit operators make

These are the errors that come up most often when operators first apply menu engineering across a large portfolio.

Using brand-wide averages without location detail. This is the most common mistake and the one that causes the most damage. Brand-wide averages belong in board-level reporting. They do not belong in menu decisions. You need location-level data to make location-level calls, and there is no shortcut around that requirement.

Cutting Dogs without understanding the operational impact. Some Dog items prop up prep efficiency or ingredient utilization in ways that are not obvious. 

If your chicken sandwich is a Dog but you use the same chicken prep for your chicken salad (which is a Star), removing the sandwich changes your prep math, your order quantities, and potentially your food cost on the salad. Model the operational impact of any removal before you execute it.

Treating LTOs as separate from core menu engineering. LTOs compete with your core menu for guest ordering behavior and kitchen bandwidth. A 10-week LTO is pulling guests away from your core Stars during that entire window. Include LTOs in your quarterly menu mix analysis so you see the full picture of where your mix sits during each seasonal window.

Engineering on price but ignoring portion drift. An item that was a Star two years ago may have drifted into Plowhorse territory because kitchen staff are serving slightly more over time. Nobody catches it. Contribution margin erodes slowly. Regular portion audits are part of menu engineering discipline, not an optional add-on.

Skipping the corrective action loop after classification. Menu engineering produces a classification. It does not produce results on its own. 

You need a documented process for what happens after you classify: who owns the action, what the deadline is, and how you verify it was completed. Without that loop, the quarterly analysis becomes a ritual that generates reports nobody acts on. You can see how this connects to a broader restaurant corrective action process.

Seasonal menu rollout across locations: the 90-day workflow

Here is what a well-run multi-unit seasonal menu rollout actually looks like in practice.

Days 1 to 30: concept, costing, and pilot launch

The culinary team develops three to five candidate items. Each goes through a cost model that calculates contribution margin at the expected menu price. Items that do not hit your minimum contribution margin target are adjusted or dropped before pilot begins. The top one or two candidates go into pilot at selected test locations. This is an operations test, not a marketing moment. The goal is data.

Days 31 to 60: pilot review, SOP build, and supply chain lock

Pull pilot data at day 30. Review velocity, food cost variance, kitchen execution time, and guest feedback. Decide whether to proceed, modify, or stop. If you are stopping, that decision at day 30 saves you from a brand-wide launch failure.

If you are proceeding, build the full SOP for the item. This includes prep steps, plating standards, temperature requirements, allergen callouts, and serving instructions. Build training content so that any location can bring a new hire up to speed on the item within one shift.

Lock supply chain before you announce a launch date. Confirm ingredient orders, pricing, and delivery schedules with suppliers. For seasonal ingredients, get lead times in writing before you commit publicly. 

You can use Xenia's Checklists and SOPs feature to digitize and distribute the new SOP to all locations simultaneously, with tracked acknowledgment so you know which locations have received and reviewed it.

Days 61 to 90: brand-wide rollout with verification

Launch brand-wide with a defined on-menu date. In the first two weeks, run a rollout verification checklist at each location confirming that ingredient stock is in place, the item is live on the POS, menu displays are updated, and staff can correctly execute the prep. Flag any location that fails the verification and assign follow-up tasks with due dates.

After 30 days, pull the ramp curve data and run the initial quadrant classification for the LTO. That data drives your sunset or graduate decision. This workflow connects directly to how well-run restaurant operations management handles new initiatives at scale. It also feeds into your broader operational excellence for restaurants framework.

District and regional leaders can track rollout completion across their portfolios through Xenia's District and Regional Leaders dashboard, so nothing falls through without someone seeing it first.

Conclusion

Menu engineering is easy in one restaurant. It gets harder when you have many locations. Different stores can have different customers, costs, and best-selling items. What works in one location may not work in another.

The best restaurant groups check menu performance for each location, not just overall numbers. They fix problems early, improve low-performing items, and plan menu changes carefully.

Seasonal menus can also help increase sales, but poor planning can create stock problems, staff confusion, and bad guest experiences across all locations. A clear process helps every location stay ready.

The key is simple: use the right data, review performance often, and take action quickly.

With Xenia, restaurant teams can manage menu rollouts, training, task tracking, and operational checks across every location in one place. Instead of chasing updates through calls, texts, or spreadsheets, your team stays aligned and every location follows the same plan.

Book a demo to see how Xenia helps multi-location restaurants run smoother and stay consistent at scale.