Export item-level POS sales for a representative period, pair each item with a consistently calculated contribution measure, and map dishes by popularity and contribution. Keep strong sellers visible, test better placement or descriptions for overlooked items, improve thin-margin favorites carefully, and rework weak items. Make one change, coach the team, then compare the sales mix.
Use menu engineering as a framework, not a promise
Toast describes menu engineering as a way to compare an item's popularity with its profitability, then use that view to guide menu design and content decisions. The useful idea is the two-part comparison: a high-selling dish is not automatically a strong contributor, and a strong contributor is not useful if guests rarely choose it.
Toast is a restaurant technology vendor, so its article is best treated as a practical framework rather than a neutral performance benchmark. Apply the method to your own POS, recipes, purchasing costs, service model, and guest feedback. The goal is not to copy a vendor's recommended outcome; it is to make one restaurant-specific decision with cleaner evidence.
- Popularity asks what guests actually order.
- Contribution asks what remains after the costs included in your chosen method.
- The test asks whether a small menu change helps guests choose well and supports the restaurant's goals.
Export a clean item-level sales mix from the POS
Start with a period that represents normal business rather than a holiday, weather event, opening week, or unusual closure. Export item quantity and sales by daypart and ordering channel if your system allows it. A dinner entrée sold in the dining room may behave differently from the same item sold for delivery.
Clean the report before drawing conclusions. Review voids, refunds, comps, duplicate menu buttons, modifier-only lines, catering orders, and items that changed size or price during the period. If the same dish appears under several buttons, combine it only after confirming the recipes and portions are truly comparable.
- Choose a representative date range and document any unusual days.
- Separate dine-in, takeout, delivery, catering, and dayparts when the economics differ.
- Resolve duplicate item names and account for voids, refunds, and comps.
- Save the original export so the test can be repeated with the same rules.
Place a consistent contribution view beside popularity
Next, give every item a consistently calculated contribution measure. Use current recipes, actual portions, and the same cost method across the set. Include packaging or channel-specific costs when they materially apply to the comparison, and ask your bookkeeper or financial adviser which method fits your restaurant. This article is educational and is not financial advice.
Do not let a single food-cost percentage decide the menu. A popular item may anchor the visit, support beverage or side orders, or express the restaurant's identity. An item with attractive unit economics may still create slow tickets, errors, waste, or guest confusion. Put operational and guest context beside the numbers before making a change.
- Use current recipe quantities and actual portion standards.
- Apply one documented cost method across every item in the comparison.
- Flag items with frequent remakes, long ticket times, or unusual waste.
- Review beverage, side, and dessert attachment before judging a popular entrée alone.
Sort items into four working groups
A simple four-group map turns the spreadsheet into decisions. Strong, popular items belong in a keep-visible group. Strong but overlooked items belong in a test-the-story group. Popular items with thin contribution belong in a pair-smarter group. Weak, overlooked items belong in a rework-or-retire group.
These groups are prompts, not automatic instructions. An overlooked item may need a clearer name, a better photo online, or a more useful place on the menu. A popular but thin item may need portion discipline or a natural beverage pairing rather than a price change. A weak item may still serve a dietary need or complete the brand promise. Record the reason before changing it.
- Keep visible: protect consistency and availability.
- Test the story: improve placement, description, or staff explanation.
- Pair smarter: test a natural add-on or tighter execution without pressuring guests.
- Rework or retire: fix a clear problem, run a limited test, or remove the item carefully.
Run one guest-facing menu test at a time
Choose one item and one change. You might move an overlooked dish to a clearer menu position, rewrite a vague description in plain language, train servers on one helpful recommendation, or create a channel-specific pairing that makes the order easier to understand. Keep the rest of the menu stable enough to learn from the result.
Prepare the operation before launch. Confirm the recipe, prep level, inventory, POS button, kitchen routing, packaging, online description, and staff language. A menu idea cannot support bigger checks or repeat visits if execution creates delays, substitutions, or disappointment.
- Define the item, audience, channel, daypart, and test dates.
- Change one main variable rather than redesigning the entire menu.
- Give staff a short explanation focused on guest fit, not a hard sell.
- Check every digital and printed menu location before the test starts.
Compare the new sales mix and protect the guest experience
After the test, compare the item mix with a similar baseline. Review quantity sold, average check, relevant attachment rates, refunds or remakes, ticket-time notes, and guest comments. Look for a coherent pattern rather than declaring victory from one busy shift.
Then make a clear decision: keep the change, revise it, restore the old version, or collect more data. Save the date range, POS export, cost assumptions, staff notes, and decision. That record turns menu engineering into a repeatable growth process instead of a one-time redesign.
- Did more guests choose the item in the intended channel or daypart?
- Did the surrounding order mix improve or weaken?
- Did execution stay consistent for the kitchen and service team?
- Did the change make the choice clearer and the visit worth repeating?
Submit a restaurant or local business.
Share the business details, useful links, and what makes the place worth knowing for possible Restaurant Tech Report coverage.
FAQ
What POS report should a restaurant use for menu engineering?
Start with an item-level sales or product-mix report that includes quantity and sales for a defined period. Add channel and daypart views when available, then clean duplicate buttons, voids, refunds, comps, and recipe changes before comparing items.
Should a restaurant remove every low-selling menu item?
No. Low sales are a prompt to investigate, not an automatic removal rule. Check the item's contribution, dietary or brand role, placement, description, execution, waste, and guest feedback. A limited rework test may be more useful than immediate removal.
How often should a restaurant review its menu sales mix?
Use a cadence your team can repeat with clean data, and review sooner after a meaningful recipe, price, channel, or menu change. Consistent definitions matter more than an arbitrary schedule because the purpose is to compare like periods and make focused decisions.