Modifier Groups Explained: How to Structure Any Restaurant Menu

Every POS menu build goes wrong in the same place: modifier groups. Get the items and prices wrong and you catch it in the first hour of service. Get a modifier group wrong, a size that isn't forced, a topping cap that never got set, a pizza half that relies on a note nobody reads, and it doesn't show up until week two, when the kitchen is fielding wrong tickets and a guest is arguing about a charge for a size they never picked. Here's how to structure modifier groups the right way, case by case.

What is a modifier group, actually?

A modifier group is a set of options attached to an item that someone picks at the moment it's ordered, size, temperature, toppings, sides. It is not the same thing as a category. Categories organize the menu so people can browse it, Appetizers, Entrees, Desserts. Modifier groups control what actually happens at the point of sale and in the kitchen once a specific item gets ordered. Mixing the two up, treating a modifier like a category or a category like a modifier, is where a lot of first-time builds go sideways.

What are the different types of modifier groups?

Most menus use some combination of these: size (small, medium, large, or a pizza size grid), temperature for proteins, toppings and add-ons, sides, sauces and dressings, preparation notes (no onion, extra crispy), combo and upsell groups, and forced substitutions when an item is out and a swap has to happen. Not every menu needs all of these, but most real menus need four or five working together correctly.

Shared modifier groups vs per-item groups: which should you use?

Shared groups, a single "Pizza Toppings" group used across every pizza on the menu, save rebuild time and keep pricing consistent for a topping across the whole menu instead of drifting item by item. Per-item groups make sense only when an item genuinely has something no other item shares, a signature appetizer with its own one-off option. The rule of thumb: if three or more items need the same modifier group, make it shared. Build it once and attach it everywhere, rather than recreating "toppings" or "sides" for the fifth time.

When should a modifier be forced vs optional?

Force a modifier when the order genuinely cannot be fulfilled or priced without it: size on a drink or a pizza, temperature on a steak, protein choice on a bowl. Leave it optional when skipping it just means the normal way, extra toppings, a special instruction, a sauce on the side. The test is simple: if leaving it blank would confuse the kitchen or break the pricing, force it. If leaving it blank just means the default, make it optional and set a sensible default so nobody has to think about it.

How do min and max picks work, and why do they matter?

Min and max settings are what actually control the choice, not just the modifier's existence. Min 1, max 1 means pick exactly one, the right setting for size. Min 0, max unlimited means pick any number, common for open-ended toppings. Min 2, max 2 means pick exactly two, the setting for a two-side combo. Forgetting to cap the max on a "choose your toppings" group is a real, quiet margin leak: a guest can add twelve toppings for the price of three, and it shows up a month later as unexplained food cost creep that nobody can trace back to a single ticket.

How do you handle pizza halves and split items?

This is one of the classic hard cases. There are two common approaches. The first is a true half-and-half modifier structure, where the item has a left half, right half, and whole pizza selector for toppings, which is the cleanest option for the kitchen because the ticket prints exactly where each topping goes. The second is treating half-and-half as a free-text note on a standard item, which is faster to set up but depends entirely on the kitchen reading the note correctly during a rush. For any pizza concept doing real volume, the structured approach is worth the extra setup time, because notes get missed under pressure and a structured modifier prints clearly every single time.

How do you structure wine and drinks by the glass vs bottle?

Most operators use two separate items, wine by the glass and wine by the bottle, rather than one item with a glass-or-bottle modifier, because the two usually have different available options; not every bottle on the list is poured by the glass. Where a wine is available both ways, some operators still keep it as two items rather than one item with a pour-size modifier, purely because it keeps sales reporting and 86'ing a pour size cleaner. Cocktails and liquor pours can use a modifier for well, call, or premium when the base recipe is otherwise identical.

How should combo meals be built?

Structure a combo as a chain of modifier groups rather than one long list: an entree choice group (forced, pick one), a side choice group (forced, pick one or two), a drink choice group (forced or optional depending on whether a drink comes included), plus an optional upsize group carrying its own upcharge. The single most common combo mistake is the upcharge logic itself, some POS systems want that price bump handled as a modifier price delta, others expect a separate combo item entirely. Decide which your system expects before you build the group, not after guests start ordering off it.

How do you handle happy hour pricing in modifiers?

There are two workable approaches: a separate menu or set of items scheduled to a specific window, or a happy hour modifier applied to an existing item that changes the price during that window. Most operators lean toward the separate scheduled menu or item, because it's easier to audit later; you can pull a report and see exactly what sold at the happy hour price. A modifier that quietly changes price during a window is harder to report on and easier to leave switched on by accident past the cutoff.

A simple checklist before you trust a modifier build

• Every group has a min and max that matches the choice being offered.
• Every required choice is forced, not left optional out of habit.
• Shared groups are actually shared, not duplicated per item under different names.
• Pricing deltas live on the modifier itself, not hidden inside item price.
• Every item with a forced or nested modifier is test-ordered before service.

FAQ