Staff will see guest instructions at the right station only if the delivery channel, integration, POS, and kitchen output pass the note through in a usable form. An order appearing in the POS is not enough. Check the actual screen or ticket each person uses, and decide what staff will do when a note is missing.
Start with one channel, one location, and one POS setup. Run a simulated order with separate item-level and order-level instructions. Match it to the kitchen and packing outputs, then repeat for each important channel and station. A vendor demonstration is useful, but the acceptance decision should reflect your restaurant's setup.
Map notes to the people who need them
Write down every ordering route you intend to connect: direct online orders and each delivery marketplace. For each route, list the devices and outputs staff use at that location. These might include a channel tablet, POS order screen, kitchen display, kitchen printer, and packing ticket. Your setup may not use all of them.
Next, identify where each instruction needs to be visible. An item note such as “sauce on the side” needs to reach the person preparing that item. An order note such as “include napkins” may be most useful at packing. If a note appears only on a front-counter screen that kitchen staff do not check, its presence in the system has not solved the service problem.
Separate free-text notes from modifiers. A guest might select “no onions” as a structured modifier, type it in an item note, or put it in the order-wide instructions. Those paths may display differently. Check modifiers and totals as part of the same order match, but evaluate the visibility of the free-text instruction on its own.
Mark any unknown path as a question, not a feature. Ask who receives order notes, whether item notes stay attached to their items, and whether staff must open another screen to read them. Also ask what happens to long notes, special characters, and notes entered after an order is placed, if the channel allows changes.
Use your actual channel and POS list when reviewing restaurant integrations. Availability and setup can vary. For an existing POS, ask both providers who owns the connection and who investigates a missing note. The guide to direct POS connections and middleware can help you frame that ownership question.
Build a safe sample order
The following is a hypothetical practice order, not a report of a completed test. Use a training environment or another vendor-approved simulation that cannot take a real card payment, send a guest message, or dispatch a courier. Do not use a real customer's name, address, phone number, or special request.
- Test identifier: NOTE-27, entered where the approved test process allows it.
- Item one: A sandwich with the selected modifier “no onions” and the item note “sauce on the side.”
- Item two: A salad with no free-text item note.
- Order note: “Include napkins.”
The identifier lets you match the source order to the POS record and each kitchen or packing output. The second item helps you see whether the sandwich note remains attached to the right item. Confirm that the selected modifier and order total match the source order too; a correct note should not hide a mismatch elsewhere.
Before running the simulation, agree on expected results with the people who will use them. For example, the cook should see “sauce on the side” beside the sandwich, and the packer should see “include napkins” on the screen or ticket used to pack. If the packer uses the kitchen ticket rather than a separate packing output, name that ticket in the test.
Ask the vendor to demonstrate the exact channel and POS combination for the location. A generic sample screen can explain the workflow, but it does not establish where a note appears in your configuration. If a channel or output cannot be simulated safely, document that gap and agree on another safe way to inspect the relevant display before relying on it.
Compare each output with its intended reader
The worksheet below shows how to record the hypothetical order. The final column contains decision rules, not observed results. Replace those rules with what you actually see during your simulation, including the device or ticket name.
| Check point | Expected result | Reader | Record and decision |
|---|---|---|---|
| Source order | NOTE-27 has the sandwich note, order note, modifier, and total | Tester | Record the source values before comparing outputs |
| POS order screen | Same order and total; both notes readable and correctly scoped | Order checker | Record exact wording and where each note appears |
| Kitchen output | “Sauce on the side” appears with the sandwich; modifier is visible | Cook | Pass only if the cook can find both in the normal workflow |
| Packing output | “Include napkins” is visible where the order is packed | Packer | Record whether a separate check or manual handoff is needed |
Check the full text rather than just looking for a note icon. A truncated instruction can be misleading. If a screen requires a tap to expand a note, ask whether staff can reasonably make that tap during a rush. On paper, check that the instruction is legible and does not blend into an unrelated item.
Record results separately for each channel and each output. A successful result on one marketplace does not establish the result for another. Likewise, a note visible on the POS screen may not be visible on a printer or kitchen display. If you use an Uber Eats integration, for example, include that channel in its own test rather than treating another channel's result as proof.
Repeat the check at each location where hardware, routing, or staff workflow differs. Note the configuration used for the test so you know what to revisit after changing a printer, display, channel, or POS setup.
Decide what to do with a missing note
Classify each result as a pass, a workable manual step, or an unresolved gap. A pass means the intended reader can see the complete instruction in the normal workflow. A manual step means a person must actively retrieve or relay it. An unresolved gap means you cannot establish a dependable path yet.
For a manual step, write down the owner and the handoff. For instance, if an order-wide note appears on a channel screen but not on the packing output, the order checker might read it and pass it to the packer before the bag is closed. That is only workable if the screen is available, the instruction is readable, and someone is assigned to check it. Do not call the integration fully automatic for that path.
Consider the workload as well as the feature list. A handoff that is manageable for a few orders may become easy to miss when several orders arrive together. Ask the vendor whether the missing field can be routed to the relevant output, what setup is required, and whether that change affects other channels or stations. Get the answer in writing with any quote for setup or ongoing support.
Some cases may be intentionally unsupported. Document the limit and decide whether your restaurant can operate around it; do not treat support for every possible note format as an automatic requirement. For instructions staff cannot safely interpret or fulfill, establish who reviews them and how the team handles the order under the restaurant's existing policies.
Assign one person to each unresolved item: a vendor contact for the connection, a manager for the operating procedure, and a station lead for the staff check. Set a decision date and a clear outcome: retest a proposed change, accept a named manual step, or leave that channel or output out of the rollout until the gap is resolved.
Use the results to make the buying decision
Compare vendors and existing POS options against the same station-level requirements. Ask for the relevant setup, support responsibilities, and operational quote in writing. Include any quoted setup, software, hardware, and support charges when comparing totals; ask separately about costs that depend on order volume or exception handling. A quote for a connection alone is not the whole operating cost.
A useful decision rule is to favor the option that meets your essential note paths in the actual workflow. If two options do that, compare their remaining manual work and quoted costs. If neither shows a critical item instruction at the cooking station, settle the path before staff are expected to rely on the connection, even if both products show the order in the POS.
Practice simulations come first. If you later choose a live service pilot, treat it as a separate rollout with staff briefed, a manager monitoring the first orders, and an agreed fallback for missing instructions. A live pilot involves real service conditions; it is not the place to run the fictional sample as though it were a guest order.
Bring your channel list, station map, and test cases to a Fleksa demo. Ask how the restaurant POS system and the connections you need would show each note at your location, and confirm availability before deciding.
Frequently asked questions
Is an order note the same as an item modifier?
No. A modifier is typically a structured selection attached to an item; a note is free text. Test both because they may follow different paths and appear in different places.
Does a note visible on the POS screen reach the kitchen?
Not necessarily. Check the actual kitchen display or printed ticket used by the cook, including whether the complete note appears beside the correct item.
How often should we repeat the visibility test?
Repeat it when you add a channel or location, change the POS or kitchen output, or alter routing. Also retest an unresolved issue after a vendor says the setup has changed.
