A complete online order starts with a simple rule: require only the choices staff need to prepare the item, and make everything else optional. Give each choice a clear name, set the right selection limit, and show its price before the guest adds the item to the cart.
Then check what happens at both ends. Can a guest understand and complete the order? Can the kitchen see the selected options without guessing? A modifier that looks clear on the menu but disappears or becomes ambiguous on the ticket has not solved the problem.
Separate required choices from extras
Start with one menu item and list the decisions needed to make it. Do not start by copying every question your staff might ask at the counter. Online, each extra decision takes attention and can slow down an order.
Consider this hypothetical meal: a grain bowl costs $14 and comes with one side. The guest must choose rice or fries. Avocado and extra sauce are optional additions. The restaurant needs the side choice to prepare the meal, but it can make the bowl without either extra.
The modifier map below separates those decisions. The limits apply to one bowl, not to an entire cart.
| Decision | Choices | Selection rule | Price |
|---|---|---|---|
| Side | Rice or fries | Required; choose exactly one | Included |
| Avocado | Add avocado | Optional; choose zero or one | $2 if selected |
| Extra sauce | Add extra sauce | Optional; choose zero or one | $1 if selected |
These are three separate decisions, even if the ordering system displays the two extras together. The side group needs a minimum of one and a maximum of one. The extras need no minimum. If they appear in one group, the guest must be able to select both without choosing either one twice.
Use labels that describe the action: “Choose one side,” “Add avocado,” and “Add extra sauce.” A heading such as “Options” makes the guest work out which decisions are necessary. Avoid a required “No extras” choice when leaving the extras unchecked already means the same thing.
Required choices should reflect preparation, not marketing. If the kitchen can make a dish as listed without asking a question, consider presenting additions as optional. If an item needs a cooking temperature, a required single-choice group may be appropriate. If it already has a standard sauce, say so in the description and label any paid option as extra sauce.
This is different from managing sold-out items. Marking fries unavailable addresses whether fries can be ordered; it does not tell the guest that a side is required. Ask how your system handles a required group when one choice, or every choice, becomes unavailable. Staff need a practical way to keep the menu orderable or pause the affected item.
Set selection limits and prices guests can follow
For each group, write down the minimum and maximum selections before configuring it. “Choose exactly one” is different from “choose up to one.” The first prevents a missing decision; the second allows the guest to skip it. A multi-select group may allow several choices, but its maximum should match what the meal and kitchen can handle.
Be equally specific about quantities. Does selecting avocado once mean one portion? Can a guest request two portions, and if so, does the system price and print both? If the restaurant does not want to offer double portions, a zero-or-one limit is clearer than leaving quantity open.
Show included options as included or $0, rather than leaving guests to infer that a side is free. Show the extra charge beside each paid choice. If an included choice can be upgraded for a charge, label the upgrade and its price in that same decision group. Ask the vendor whether the display shows the additional amount and the updated item price before checkout.
For the hypothetical bowl, a guest choosing fries, avocado, and extra sauce should see an item total of $17: $14 for the bowl, $0 for the included side, $2 for avocado, and $1 for sauce. That is the menu item price only. It excludes order-level charges such as delivery, service fees, and applicable tax. It is not an estimate of the restaurant’s processing fees or operating costs, including fixed, variable, or exception costs.
If the guest removes avocado, the item total should fall to $15. If the guest orders two identical $17 bowls, the item subtotal should be $34. If the bowls have different sides, each bowl’s selections should remain attached to the right item. That matters when staff pack meals separately.
Keep the number of choices manageable. A long list of sauces, substitutions, and preparation notes may be necessary for some dishes, but split it into understandable decisions rather than one crowded group. Ask whether the ordering system supports the minimums, maximums, prices, and item-level summaries your menu requires. The broader online ordering guide can help frame that question alongside checkout and fulfillment needs.
Simulate incomplete and complete carts
Before changing the live menu, ask for a sandbox, preview, or other safe way to exercise the setup. A practice check must not charge a real card, send a guest message, or dispatch a courier. If the vendor cannot prevent those actions in a preview, ask it to demonstrate the scenarios without submitting a real order.
Work through the bowl as a guest would, including mistakes. Check the message, the selections, and the total rather than merely confirming that the item appears on screen.
- Leave the side unselected. Try to add the bowl. The guest should be told to choose a side, with the relevant group easy to find. A generic “invalid item” message does not explain what to fix.
- Try both sides. Confirm that the interface enforces one side and makes the current selection obvious. Changing from rice to fries should not leave an unintended extra side attached.
- Skip both extras. Choose rice and confirm that the item can be added for $14. Optional extras should not block an otherwise complete item.
- Add both extras. Choose fries, avocado, and extra sauce. Check for the $17 item total and for all three selections in the cart summary.
- Edit the item. Remove avocado and confirm that the summary and item total change to $15. Then add a second bowl with a different side and check that the choices remain with their respective bowls.
Also inspect the menu on a phone. Are labels and prices visible without opening several screens? Does the cart show enough detail for a guest to catch a wrong side? A guest should not have to guess whether an extra was saved.
A simulation checks the configured behavior without involving guests or fulfillment. A live service pilot is a separate step: after the practice checks pass, decide who will monitor actual orders, how staff will report confusing tickets, and how to revert a change if it causes trouble. Use normal service controls for real orders; do not turn a practice scenario into a live payment or dispatch.
Make the order understandable to staff
A correct cart is only half the job. Review the order as it reaches each person who needs it: the kitchen, the packer, and the person handling guest questions. Ask the vendor to show a representative order display or ticket for the same bowl, including the side, both paid extras, and an item-level special instruction.
Staff should be able to tell the difference between a selected, paid option and a note. “Add avocado — $2” is a menu choice with a defined charge; “please put sauce on the side” is a preparation instruction. A free-text note saying “add avocado” should not be treated as proof that the guest selected or paid for the avocado modifier.
Agree on a response before that situation occurs. For example, staff might follow the restaurant’s normal process for clarifying an unclear request rather than silently adding a paid extra. Keep that process short and make sure the front-of-house team knows who can resolve it.
Look for other ticket ambiguities. If two bowls appear on one order, are their different sides and extras grouped with the correct bowl? If an option is removed during editing, does it disappear from the final staff view? Can the packer distinguish included sauce from extra sauce? If the display uses abbreviations, make sure staff understand them and that similar options do not look alike.
After launch, review questions and corrections with staff regularly. A repeated request to explain a modifier may mean the label is unclear; repeated kitchen clarification may mean the ticket needs a better grouping. Change one issue at a time where practical, then repeat the relevant safe simulation before relying on the new setup.
Pick one frequently ordered item and write its required choices, optional extras, limits, and prices before your next vendor conversation. Review Fleksa’s restaurant online ordering page and, if it fits your restaurant, ask for a demonstration of that item from menu selection through staff display. Also consider how the ordering link will appear on your restaurant website.
Frequently asked questions
What should be a required modifier?
Make a choice required when staff need the guest’s answer to prepare the item, such as one included side with no default. Use optional choices for additions the guest can skip.
Should special instructions replace paid modifiers?
No. A defined paid modifier gives the guest a visible price and gives staff a recognizable selection. Use special instructions for preparation details, not as evidence that an extra was selected or paid for.
How often should a restaurant review modifiers?
Review them when an item, price, or preparation process changes, and when staff repeatedly need to clarify orders. Recheck the guest cart and staff display after a change.
