Online order notes can show where guests are working around a confusing menu or checkout. Review a defined sample, group similar requests, and compare the largest group with the choices guests actually see. A repeated request for sauce on the side, for example, may point to a missing selection—or simply to a popular preference worth making easier to choose.
Notes are clues, not proof. Before changing a menu, check whether guests already have an option, whether staff can fulfill it consistently, and whether the same request appears after a correction.
Choose a useful sample without keeping guest details
Start with a recent two- or four-week period that represents normal service. Record the dates and the ordering channels included. If a holiday menu or an unusual promotion dominated the period, note that context or select a different window. A sample from only one busy Friday may reflect that shift rather than a persistent problem.
Ask the person who manages orders to identify how many orders came through each included channel and how many contained a note. A shift lead can explain which requests slowed preparation or needed clarification. The person responsible for the menu can then compare those requests with the current ordering screens. One person should own the final decision so observations do not stop at a spreadsheet.
Use the order count as well as the note count. Ten similar notes out of 50 orders deserve a different reading from ten out of 2,000. Also keep channel totals separate when screens or menus differ. A request that appears mainly on one channel may be connected to that channel's presentation.
Do not copy names, phone numbers, addresses, payment details, or full free-text notes into the working sheet. Replace each note with a short, neutral summary and a code. Use a non-identifying row number if you need to count entries; it does not need to link back to the guest. Keep any operational access to original orders limited to staff who need it, and follow the restaurant's own retention practices.
Some notes contain sensitive information, including allergy details. Summarize the operational issue without recording the personal detail. A coding exercise does not replace the restaurant's normal process for handling a live allergy request or other urgent instruction.
Code the issue, not the guest
Give each note one primary code based on what the guest is trying to accomplish. Add a secondary code only when it represents a genuinely separate issue. That makes the main counts easier to interpret while preserving useful detail. Record an uncertainty flag when the note is too vague to classify confidently.
The following is a hypothetical, anonymized coding template. The summaries are invented, not actual guest notes. Each row represents one note; the suggested check is a question for the owner, not a conclusion about the cause.
| Row | Neutral summary | Primary code | Check |
|---|---|---|---|
| 01 | Sauce requested separately | Preparation placement | Can the guest select sauce on the side? |
| 02 | Rice requested instead of salad | Side substitution | Is a side choice offered for this item? |
| 03 | Guest asks which sauce is included | Menu description | Does the item description name the sauce? |
| 04 | Guest requests an unavailable ingredient | Unavailable request | Is the ingredient offered elsewhere, or not offered at all? |
| 05 | Preparation request is unclear | Uncertain | Can staff interpret it without guessing? |
Use codes that match your menu, but define them before counting. For example, put “sauce on the side” and “please pack dressing separately” under preparation placement if they require the same kitchen action. Keep a request to remove sauce separate if it calls for a different choice and a different fix.
Do not treat every note as a defect. A guest may be sharing a preference even when the correct option is visible. An unavailable request may also be a deliberate menu boundary. Count it so you understand demand, but do not assume the restaurant should fulfill it.
Compare the pattern with the ordering screen
For each leading code, follow the guest's path from item selection through checkout. Look at the item name, description, available choices, and the point at which a note can be entered. Check the same item on the relevant phone and desktop views if guests use both. A menu manager should confirm the current configuration; a kitchen lead should confirm what staff actually do with the requests.
Use these questions to narrow the cause:
- Is the requested choice absent, or present under a label a guest might not recognize?
- Does the description say what comes with the item before the guest has to choose?
- Is a choice visible for some related items but not others?
- Does the request require a substitution the kitchen cannot consistently make?
- Could a clearer description solve the issue without adding another selection?
Consider a separate hypothetical review of 240 direct orders over four weeks. Assume 48 orders contain notes, and 18 of those notes request sauce on the side. That is 18 of 240 orders, or 7.5% of all orders, and 18 of 48 note-bearing orders, or 37.5% of those orders. These are counts of requests, not counts of confused guests.
Suppose the item screen names the sauce but offers no side-placement choice, and the kitchen lead says the request is routinely achievable. A labeled choice is a reasonable candidate to test. If the choice already exists and is easy to find, the better next question is whether its wording or placement needs attention. If separate packing creates a service problem, discuss that cost and workflow before offering it broadly.
Prioritize by frequency and operational effect, not frequency alone. A less common but ambiguous preparation request may deserve attention if staff must interrupt service to clarify it. Conversely, a frequent request that is easy to fulfill may be useful to address but not urgent.
Test one correction and review the result
Choose one change tied to the observed issue. In the sauce example, the owner might add or rename a side-placement choice if the ordering setup supports it and the kitchen agrees to the workflow. Ask the provider how choices appear on each ordering channel and how selections reach the kitchen. Do not assume a change on one screen updates every channel.
Before publishing, run a simulated check with staff. Use a preview or test environment where available, or inspect the configured screens without submitting a live order. Have one person try to find the choice while another checks the wording against the intended kitchen action. The simulation must not trigger a real card payment, guest message, or courier dispatch. If the provider cannot offer a safe test path, ask how to verify the configuration without those actions.
Then, if the correction is ready, publish it as a live service change and tell the team what to expect. A live pilot uses genuine incoming orders, not practice orders disguised as guest purchases. Tell staff how to report confusing selections or kitchen tickets, and keep the normal process for handling actual orders in place.
Review a comparable period after the change. Record the number of orders, note-bearing orders, and notes in the target code, using the same channel and coding definition as before. Also ask staff whether the new choice is understandable and workable. A lower count of sauce notes may suggest that guests are using the choice, but check whether the system can report choice selections before making that inference. A menu change, promotion, or shift in order volume can affect the comparison too.
If the target notes remain common, inspect the label and placement again. If staff find the choice impractical, revise the workflow or remove it. Keep a short decision record: the code, the change, the review dates, what happened, and the next action. That record makes the next review faster and prevents the team from repeatedly debating the same issue.
Use the findings when evaluating ordering software
A note review can turn a broad software search into specific requirements. Bring the provider one anonymized example and ask to see how an item description, a preparation choice, and the resulting kitchen information are configured. Ask who can make edits, whether changes apply separately by channel, and how to review the effect afterward. If a feature matters to your decision, request a demonstration using your own menu structure rather than relying on a general feature list.
For broader context, the online ordering buying guide covers the wider purchase decision. Also check how your restaurant website presents menu information before guests start an order.
Next, code a recent sample, pick one recurring issue, and walk through the relevant item screen with your shift lead. If your current setup cannot support the correction, ask Fleksa about its restaurant online ordering setup and verified availability in your US location.
Frequently asked questions
How many order notes should I review?
Start with a recent two- or four-week period and count all orders in the included channels as well as orders with notes. If the sample is small or unusual, extend the period before treating a pattern as representative.
Should every repeated request become a menu option?
No. Check whether the option already exists, whether the kitchen can provide it consistently, and whether adding it would make ordering clearer. Some requests are preferences or substitutions the restaurant chooses not to offer.
How can I tell whether a menu correction worked?
Compare the target note code over similar periods using the same channel and definitions. Pair the count with staff feedback and, where available, selection data. Other menu or demand changes can affect the result.
