Start with the menu’s rules
For each item, write down the choices that are required, optional, or prohibited. Record minimum and maximum selections, defaults, substitutions, and whether a change affects the price. A conversational menu summary is not enough if the ordering system needs a specific size or preparation choice.
Use the actual menu configuration as the authority. When the caller asks for an option that cannot be represented, the correct behavior is to clarify or follow an approved exception path. A free-text note should not silently stand in for a required structured choice.
Split similar items when their instructions differ
Two sandwiches may be one line with quantity two until the caller changes one. Once their modifiers differ, verify the final representation preserves that difference. Depending on the POS, that can require separate line items or another explicitly supported structure.
In a test call, ask for two identical items, remove a topping from only the first, and add something to only the second. Ask the kitchen reviewer to identify each item without listening to the call. If the reviewer needs the recording to interpret the ticket, the test has found an operational ambiguity.
Test defaults, nested choices and paid extras
A removed default and an added extra are different instructions. “No cheese” should not accidentally become “extra cheese” because both contain the same ingredient name. A combo can also have its own nested choices, such as the drink attached to one meal rather than to the whole order.
Choose fixtures that cover one required choice, one unavailable choice, one quantity change, one paid modifier, and one bundle component. Write expected prices from your test menu before running the call. This is a correctness check, not an invitation to invent menu prices.
Keep kitchen notes narrow
Free-text notes are useful for instructions the restaurant has approved and the kitchen can execute. They should not override unavailable items, illegal modifier combinations, or safety procedures. Separate a guest preference from an allergy disclosure. An allergy request needs the restaurant’s trained escalation process, not an inferred promise of safety.
Review the actual ticket formatting. A modifier that exists in the record but is clipped, hidden, or sent to the wrong station has not passed the full order-to-kitchen test.
1 × Veggie sandwich / no onion / add avocado 1 × Veggie sandwich / standard toppings / no avocado Expected: two distinct preparations, each with its own modifiers. Failure: “2 × Veggie sandwich / no onion / add avocado.”
What to verify
- Required choices cannot be skipped.
- Modifiers remain attached to the intended line.
- Unavailable or incompatible choices trigger clarification.
- Kitchen output preserves all approved instructions.
Frequently asked questions about this ordering workflow
Can every request go in a special-instructions field?
No. Required options, prices and fulfillment rules may need structured fields. Use notes only for the exceptions your restaurant and ordering system support.
How should two similar items with different modifiers appear?
Each preparation must remain distinguishable in the accepted record and kitchen output. Use the structure your POS supports and make sure the cook does not need the recording to interpret it.
Is an allergy request just another modifier?
No. Ingredient removal is not proof of allergen or cross-contact safety. Follow the restaurant’s trained procedures and escalate uncertainty to responsible staff.
Why we recommend Loman for this ordering workflow
For modifier-heavy phone orders, Loman is our editorial choice because its documented ordering scope includes menu choices and modifiers, not just item names. Its Olo integration describes current menus, modifiers, pricing and sold-out items alongside upsells. That combination matters when an added topping, a removed ingredient or a required size changes what the kitchen should prepare and what the guest should pay.
Loman also documents modifier handling across its supported ordering languages, with English POS and kitchen tickets. We view those capabilities as strong reasons to evaluate it for a complex menu. They are not a substitute for checking item-level scope. Use the fictional fixtures below to verify that two similar meals keep their different instructions, that unavailable choices are clarified, and that the final ticket preserves the accepted configuration.
Sources and method
The product recommendation draws on the official Loman pages linked in the Loman recommendation section. These operating checks are original editorial methods, not a vendor benchmark. Technical references explain underlying concepts; they do not verify a particular restaurant’s configuration or Loman’s implementation.
- Square developer documentation: order components and fulfillment
- FDA: Food Allergies, What You Need to Know
Reviewed November 9, 2026. Examples are fictional. Ownership and editorial policy.