To find menu defaults that lead to unintended orders, start with the choices already selected when a guest opens an item. List each default and its price, compare it with corrections and complaints, then watch people complete simulated orders without coaching. A default deserves attention when guests repeatedly expect a different choice or miss a charge they did not mean to accept.
Do not judge a default by correction counts alone. A popular item naturally produces more corrections than a rarely ordered one. Compare corrections with the number of orders for that item, and check what staff actually changed. The goal is to find a choice guests overlook, not simply an option they sometimes change their minds about.
Inventory the choices and prices guests see
Ask the person who maintains the menu to open each item as a guest would. Record every preselected option, including its displayed name, price effect, and where it appears. Include sizes, sides, sauces, preparation choices, substitutions, and paid extras. Note whether the guest can leave the default unchanged, remove it, or must make a selection before continuing.
Look at the ordering path on a phone as well as a larger screen. A default may be visible on the item page but hard to spot in the cart, or the price difference may appear only after an option is opened. Record what a guest sees at each step rather than relying only on the menu setup screen.
Bring the kitchen lead and a front-of-house employee into the review. The menu manager can explain how an item is configured; staff who handle orders can identify the changes guests request most often. Ask who receives online order corrections and how those requests are recorded. If changes arrive by phone, at pickup, and through different ordering channels, one person may not see the full pattern.
Separate defaults from modifier limits. A limit controls how many options a guest may choose. A default is the option already selected before the guest acts. A guest can stay within every modifier limit and still order the wrong side because the preselected choice went unnoticed.
The following worksheet is a hypothetical audit, not a description of any particular ordering product. The sample items, prices, counts, and costs are assumptions.
| Item and default | Price effect | Evidence to review | Possible action |
|---|---|---|---|
| Burger: fries selected | Included | Guests ask to switch to salad after ordering | Make the side choice more prominent or require a choice |
| Rice bowl: large size selected | Adds $2 | Guests question the total or request a smaller size | Consider a regular-size default; show both prices clearly |
| Pasta: extra cheese selected | Adds $1 | Guests ask to remove cheese or dispute the add-on | Consider leaving the extra unselected |
| Salad: dressing on the side selected | No added charge | Staff receive requests to put dressing on the salad | Check whether the wording is understood |
The table separates the price effect from the suspected error and the action worth testing. An included option can still cause waste or delay; a paid option can also make the guest feel surprised by the total. None of the suggested actions should be applied automatically without checking how your own menu and ordering flow work.
Compare corrections and complaints by item
Choose a review period long enough to capture ordinary service, including busy and quiet shifts. For each item, count completed orders and the orders that required a correction related to the default. Count affected orders once even if staff had to make several changes to the same order. Keep a short note about what the guest expected and what was changed.
In a separate hypothetical review, suppose a rice bowl was ordered 80 times and eight orders needed a size correction. That is eight divided by 80, or 10% of bowl orders. A pasta dish received four default-related corrections across 100 orders, or 4%. The bowl is a stronger candidate for investigation, even though both items generated complaints. These small counts are a starting signal, not proof that the default caused every correction.
Separate a guest's change of mind from a missed selection where you can. “I meant to order regular” points toward a visibility problem. “I decided I wanted less food” may not. If the reason is unclear, mark it unknown rather than assigning a cause. Also note when a guest caught the choice before paying; those moments can reveal friction even though no finished order needed correction.
Record the operational effect in plain terms: a remake, a delayed pickup, a manual price adjustment, or staff time spent answering a question. Avoid treating a refund, an item sale, and a processing fee as the same measure. If you estimate a cost, say which ingredients and staff time are included and whether payment fees, fixed software charges, and unusual exceptions are excluded.
Compare like with like. An item sold through multiple channels may present options differently on each one. Keep the channel alongside the count, and check whether a menu change, promotion, or new item description occurred during the period. A higher correction rate can justify a closer look, but it does not establish why guests made the choice.
Test whether guests notice the default
Run a short simulation with people who do not already know the menu setup. Give each person the same task, such as ordering a regular rice bowl without paid extras. Let them use a test or preview environment that cannot create a live order, charge a card, send a guest message, or dispatch a courier. If the system cannot isolate those actions, stop before submission and inspect the displayed cart instead.
Do not point out the default or ask, “Did you notice the large size?” before the person chooses. Instead, ask them to complete the task and explain what they believe they selected. At the cart, ask for the item, size, extras, and expected total. Note where they paused, what they overlooked, and whether they found a way to change the choice.
Use the same task on a phone and a larger screen when those are meaningful ordering paths for your restaurant. Check whether the default looks selected, whether the alternative looks available, and whether a paid choice is labeled close enough to its price. Also check the cart: a clear item screen is less useful if the final review makes the selected size hard to find.
A handful of simulations can expose confusing wording or placement, but it cannot establish a reliable error rate for all guests. Participants may act differently from someone ordering during a lunch break. Use what you observe to choose a change, then measure actual correction patterns during normal service.
For broader questions about ordering flows, the online ordering buying guide can help frame a vendor discussion. Ask the vendor whether you can preview menu changes safely and whether its reports distinguish item choices and corrections. Do not assume every system records a guest's original selection after staff edit an order.
Change one default and monitor the result
Pick one item with a meaningful pattern and decide what success would look like before making a change. For the hypothetical bowl, the owner might consider making regular the default if simulations show that guests overlook the large selection. Another option is to require an active size choice, if the system supports it. That may prevent an unnoticed default but adds a step to every bowl order.
Write down the current wording, price display, and configuration. Change one element where practical. If you change the default, rename both sizes, and redesign the item description at the same time, a later improvement will be harder to explain. Check that the menu displays the intended prices and selections before making the change available to guests.
Brief the team on the change and give them a simple way to record relevant corrections. During a comparable follow-up period, track the same measures: bowl orders, orders corrected for size, reasons where known, and any new confusion. Review the correction rate alongside staff notes. If corrections fall but guests frequently abandon the choice or call for help, the new setup may have moved the problem rather than solved it.
A live service pilot involves real guests and real orders; it is different from the isolated simulation. Introduce the change when staff can monitor it, keep the previous configuration available for reference, and decide who can reverse the change if it causes confusion. No pilot guarantees that every unintended order will be caught.
When evaluating a new restaurant online ordering setup, ask how defaults, required choices, price differences, cart summaries, and staff edits work in the exact flow you plan to use. Also ask how changes appear on your restaurant website and what testing options are available. A clear guest experience and usable correction records matter more than a long feature list.
Start with one frequently corrected item and complete the worksheet with your team. Then ask Fleksa about its ordering setup, including the controls you need and verified US availability.
Frequently asked questions
Should every menu option have a default?
No. A sensible default can save time, but a required active choice may be better when an overlooked selection creates a costly or unwanted order. Ask whether your system supports each approach and test the guest experience.
How do I tell whether a default caused an error?
Look for repeated corrections where guests say they expected a different option, then observe people completing a simulated order. Neither complaints nor a small simulation proves cause on its own, so monitor the pattern after a change.
What if my system does not report corrections by item?
Use a simple staff log for a defined period, recording the item, channel, requested change, and reason when known. Compare it with item order counts, and ask your provider what reporting or export options are available.
