Name each online ordering choice so a guest can tell what they will receive, how the kitchen should prepare it, and whether the price changes. Use the food or action in the label: “Add avocado” is more useful than “Extra,” and “No onions” is clearer than an unchecked box labeled “Onions.” Show any added charge beside the choice before the guest commits.
Modifiers are the choices attached to an item, such as a protein, an extra topping, or an instruction to leave something off. They are different from the item names on your restaurant website. A well-named sandwich can still produce a confusing order if its options say only “Regular,” “Plus,” and “Special.”
The buying decision is whether your ordering setup lets you present those choices in language guests understand and staff can act on. Review the words, the price display, the selection rules, and the resulting kitchen ticket together. Clear labels cannot compensate for a system that displays the wrong total or hides a required choice.
List the options guests could misread
Start with items that generate questions, remakes, or handwritten clarifications. Open the ordering page as a guest and write down every option exactly as it appears. Include the group heading, the choices underneath it, any displayed price, and the rule for how many choices a guest can make.
Look for words that depend on knowledge the guest may not have. “Regular” might mean the standard portion, the default recipe, or a sauce with no heat. “On the side” needs an object: is it the dressing, the cheese, or the whole topping? “Extra” needs both an ingredient and a reference point. If the base item already includes cheese, does extra cheese mean another portion or a replacement?
Ask the kitchen lead what each selection should produce on the ticket. Ask the person responsible for menu pricing what is included in the base item and which changes carry a charge. Front-of-house staff can identify questions they hear from guests. The owner or menu manager should settle any disagreement before changing labels; a wording fix is not useful if staff still interpret the choice differently.
Pay particular attention to these common sources of ambiguity:
- Size or amount: “Large” may describe the meal, a drink, or a side. Name the thing being changed.
- Add versus replace: “Chicken” does not say whether chicken is added to the existing protein or substituted for it.
- Removal versus exclusion: “No cheese” should remove cheese from the standard recipe, not imply that a cheese option was simply left unselected.
- Preparation: “Light” could mean less sauce, less seasoning, or a lighter cooking level. Specify the ingredient or action.
- Required choices: A guest should know when they must select a side and whether the standard item already includes one.
Keep labels short enough to scan, but do not remove the words that explain the action. If the system truncates a label on a phone or kitchen ticket, ask how it handles longer text and where guests and staff can see the full wording.
Add price and quantity context
The price beside an option should answer a simple question: how much more will I pay if I select this? Use “Included” for a choice covered by the base item and a clear added amount for a surcharge. Do not rely on a guest to infer that a number is an extra charge rather than the full item price. Check that the cart reflects the same amount.
Use group headings to explain selection limits. “Choose one side” is more useful than “Sides.” If a meal includes one side but a second side costs more, explain that rule where the guest chooses, not only at checkout. If the interface cannot express the rule clearly, ask the vendor how to configure it or consider separating the choices into groups.
Here is a hypothetical menu setup. A bowl costs $12 and includes one standard protein and one sauce. A guest may replace the standard protein with shrimp for $3 more or add avocado for $2. One sauce is included; an additional sauce costs $1. These are assumed menu prices, not software fees.
For a bowl with shrimp, avocado, and two sauces, the item total is $18: $12 base + $3 protein replacement + $2 avocado + $1 additional sauce. The example includes those item-level charges only; it excludes any order-level delivery charge, payment fee, and applicable tax. A guest choosing shrimp needs to see that it replaces the standard protein, while the kitchen needs the ticket to show the selected protein and both sauces.
Use the following sheet to connect the guest-facing words with the result staff expect. The prices and portions are assumptions for this example; replace them with your own menu rules.
| Unclear choice | Clearer guest wording | Expected result | Check |
|---|---|---|---|
| Protein: shrimp | Replace standard protein with shrimp +$3 | Shrimp instead of the standard protein | Only one protein selected; total rises $3 |
| Avocado: extra | Add avocado +$2 | Avocado added to the bowl | Ticket shows avocado; total rises $2 |
| Sauce: regular | Choose one sauce: herb sauce included | One portion of herb sauce | Required selection appears without a surcharge |
| Extra sauce | Add a second sauce +$1 | One additional sauce portion | Guest can identify the sauce; total rises $1 |
Check whether “second sauce” requires another selection to identify its type. If it does, the flow should make that choice obvious. If a quantity has a standard meaning in your kitchen, such as one cup or one scoop, consider stating it; avoid a precise measurement unless staff can reliably provide it.
There is a trade-off between detail and speed. A long label may crowd a phone screen, but a short label can create a costly misunderstanding. Put the action and ingredient first, then add the price or portion detail needed for a decision. Ask vendors whether prices, selection limits, and full modifier names remain visible on both the guest screen and the order output.
Test the wording with people unfamiliar with the menu
Before publishing changes, ask a few people who do not know the menu to use a preview or simulated ordering environment. Give them a goal rather than explaining the labels. For the hypothetical bowl, ask them to select shrimp instead of the standard protein, add avocado, and choose two sauces. Then ask what they expect to receive and what item total they expect before order-level charges.
Watch where they pause, change a selection, or interpret a word differently from the kitchen. Record their answer before correcting them. A useful test checks comprehension, not just whether someone can tap through to a cart. Someone may finish quickly while believing that shrimp comes in addition to the standard protein.
Use a test setup that cannot take a real payment, send a guest message, or dispatch a courier. If a safe preview is unavailable, walk through screenshots or a paper version and calculate the expected cart total separately. Do not place a live order merely to practice the wording.
Test the staff side too. Give the kitchen lead the simulated order output without explaining the guest’s task. Ask what they would prepare and compare that answer with the tester’s expectation. Check whether a replacement is shown as a replacement and whether a removal is visible. A guest-facing label and a kitchen ticket can each look clear on their own while telling different stories.
A small informal test can reveal confusing words; it cannot establish an error rate for all guests. Include a phone-sized view where possible, since cramped screens can hide context. For a broader evaluation of the ordering flow, use the online ordering buying guide alongside this menu-specific check.
Review order errors and revise the sheet
After a wording change goes live, give staff a simple way to note relevant problems during normal service. Record the item, the modifier as displayed, what the guest expected if known, what the kitchen prepared, and whether a remake or clarification was needed. Avoid collecting more guest information than the team needs to resolve the issue.
Separate a wording problem from other possible causes. A guest may understand “No onions” correctly even if onions are added by mistake. Conversely, a kitchen may follow the printed ticket correctly while the guest misunderstood what “extra” would add. Review the screen, cart, and ticket before deciding which part needs a change.
Keep the test sheet current. Add the revised label, the expected kitchen result, the price or included status, and a pass condition such as “guest identifies shrimp as a replacement.” When a menu price, recipe, or portion changes, check the associated modifiers as well. A label that was accurate last month can become misleading after a recipe change.
Ask your ordering provider how staff can edit modifier text and prices, set required or optional choices, limit selections, preview the guest view, and inspect the order output. Also ask how changes reach each ordering channel you use. Confirm the answers in a demonstration using one of your own menu items rather than assuming every setup works the same way.
As a next step, choose one frequently customized item and complete the four-column sheet for its most confusing options. Run the simulated guest and kitchen checks, then ask Fleksa about its restaurant online ordering setup and verified US availability for your location.
Frequently asked questions
Should a modifier say “included” when it has no extra charge?
Yes, when that helps distinguish an included choice from a paid upgrade. Check that the cart and kitchen output match the label, and make clear whether the guest must select the included option.
How specific should a portion label be?
Specific enough to set a useful expectation. Name the ingredient and describe the portion if your team can provide it consistently. Avoid exact measurements that do not reflect how the kitchen actually serves the item.
Can I test modifier wording without placing an order?
Yes. Use a safe preview or simulated environment, or walk through screenshots with a sample task. Confirm that the exercise cannot trigger a real payment, guest message, or courier dispatch.
