Designing modifier groups

Modifiers are where a menu stops being a list and becomes an instruction set. They decide whether the guest gets what they asked for, and they are the single most common source of remakes — which cost you the food, the labour and the ticket time twice.

Structure: required, optional, and how many

Every modifier group answers one question about one dish, and the useful distinction is whether the answer is genuinely required. A required group blocks the order until it is answered, which is right for a choice the kitchen cannot make on the guest's behalf and wrong for anything else.

• ✓Make a group required only when there is no sensible default. Temperature on a steak is required; sauce on the side is not.
• ✓Set defaults wherever a default exists, so most guests accept rather than choose.
• ✓Watch minimum and maximum selections — a group allowing unlimited picks will eventually produce a ticket no kitchen can execute.
• ✓Reuse groups across items rather than rebuilding them. One shared group edited once beats eleven near-identical ones edited never.

Naming is the whole game

A modifier is read twice by two audiences with opposite needs: a guest choosing, and a cook executing under pressure. Kitchen shorthand confuses the guest; a florid guest-facing description slows the cook. The name has to work for both, which usually means plain, short and specific.

• ✓Say what changes, not what it is called internally. 'No onion' beats an abbreviation nobody outside the kitchen uses.
• ✓Keep negatives unambiguous. 'No cheese' and 'extra cheese' should not be one character apart on a ticket.
• ✓Avoid near-duplicates. Two options a cook has to squint at will eventually be executed as each other.
• ✓Be consistent across items. If it is 'well done' on one dish, it is not 'cooked through' on another.

Modifiers that change money or availability

Priced modifiers deserve a check of their own, because an add-on that costs the kitchen real money and is priced at nothing is a leak that scales with popularity. Cost the significant ones the way you cost a dish.

Availability matters too: a modifier that adds an ingredient you have run out of should not remain orderable when that ingredient is 86'd. Worth testing deliberately, because it is a common gap.

How this works in Opero

Modifier groups in Opero are defined once and shared across the items that use them, with selection rules validated server-side rather than trusted from whichever surface sent the order. That matters when the same menu is being ordered from the POS, a kiosk, a QR code and web ordering — the rules cannot drift between channels because there is only one set.

Because the kitchen display is part of the same system, the modifier the guest chose is the text the cook reads: no relay, no middleware translating between an ordering system and a printer. Which is precisely why the naming work above is worth doing once and properly.