A delivery order reaching your POS is not enough. The required choices, optional extras, quantities and prices must reach the POS in a form your kitchen can use. To find out whether they do, trace one controlled order from the marketplace through the integration to the POS and kitchen display or ticket.
Use a meal with a required choice and a paid extra, then compare each selection and the order total at every step. Repeat the check for each marketplace, location and POS combination you intend to use. A successful item mapping does not, by itself, prove that its modifiers map correctly.
Choose a meal that exposes modifier problems
Start with an item your staff understands and that has several kinds of choices. A bowl, pizza or burger can work well. Include a required selection, an optional instruction and a priced add-on. If your menu uses nested choices, such as selecting a sauce after choosing an extra, include one of those in a separate case.
Write down the channels and locations you want to connect. The same menu can be configured differently across marketplaces or stores, so a result for one combination should not stand in for another. Note the POS in use at each location and how the kitchen receives orders: on a display, a printed ticket or both.
Here is a hypothetical example for the worksheet below. A rice bowl costs $12. A guest must choose a base at no extra charge and may add avocado for $2 per bowl. The guest orders two bowls: one with white rice and avocado, and one with brown rice and no avocado. The food subtotal should be $26: two bowls at $12 each, plus one $2 avocado add-on.
That subtotal includes the items and selected modifier. It excludes fixed software charges, delivery charges, payment processing, tax and any exceptional handling costs. Those excluded amounts are not modifier prices, and they should be identified separately if the systems show them.
Before testing, ask how the marketplace represents two differently customized bowls: as separate lines or as a quantity with individual choices attached. Either representation needs to preserve which base and add-on belong to which bowl. A combined list of modifiers is not enough if the cook cannot tell them apart.
Trace each selection to the POS and kitchen
Give the practice order a unique test identifier and use it to match the source order to the POS record and kitchen output. Do not use a real guest's name, address or phone number. The identifier matters because an unrelated order with similar items can otherwise look like a match.
The table is an acceptance sheet for the hypothetical bowl order. Its expected results describe what the restaurant needs; they do not assert that any particular integration supports it. Record the actual result beside each row when the provider demonstrates your combination.
| Check | Source selection | Expected POS and kitchen result | Result and owner |
|---|---|---|---|
| Item and quantity | Two rice bowls | Two bowls appear, with choices distinguishable by bowl. | Not checked; manager to compare lines. |
| Required base | White rice on one; brown rice on the other | Both choices appear with the correct bowl on the POS and kitchen output. | Not checked; manager to inspect both outputs. |
| Paid add-on | Avocado on the white-rice bowl only | Avocado appears on that bowl; the POS assigns the $2 charge once. | Not checked; provider to demonstrate mapping. |
| Food subtotal | $24 for bowls plus $2 for avocado | POS food subtotal is $26; other charges remain separately identifiable. | Not checked; manager to reconcile totals. |
| Missing required choice | Attempt to proceed without a base | The ordering flow prevents submission, or the restaurant has an agreed way to resolve the missing choice before preparation. | Not checked; provider and manager to agree on handling. |
Check the source, POS and kitchen views independently. The POS may show a modifier that does not appear on the kitchen ticket, or the ticket may show an instruction without its associated charge in the POS. Both matter. The cook needs an actionable order; the manager needs a record that explains the amount charged.
Also check how special instructions are represented. If “no onions” is an optional modifier, does it arrive as a clear instruction on the correct item? If the channel treats it as free text instead, ask where that text appears and whether staff must move it manually. Do not assume a note and a structured modifier behave the same way.
Run a safe simulation, then decide on a live pilot
Ask the provider for a demonstration or simulated order in an environment that cannot create a real card charge, send a guest message or dispatch a courier. Confirm those safeguards before starting. A practice order should not depend on a real payment, a real guest notification or a real delivery.
In the simulation, select the two bowls exactly as written. Capture the source selections and expected subtotal first. Then compare the corresponding POS record and kitchen output. Mark each row pass, fail or unresolved, and record what actually appeared. A screenshot or redacted ticket can help the team review the result without storing private customer information.
Test the required choice separately by attempting to leave it blank. If the source channel blocks submission, record that behavior. If an incomplete order can reach staff, agree who notices it and what happens before the meal is made. Do not mark the case as passed merely because the order arrived.
Next, try a supported exception in the safe environment. For example, ask the provider to demonstrate what happens when an order is canceled or changed, if that action is supported for the combination being evaluated. Compare the resulting status and instructions across the available views. If a change must be handled manually, write down who performs it and how the kitchen is informed.
A simulation checks the demonstrated path; it does not prove how every live order will behave. If you later choose a live service pilot, agree on its scope, staff coverage and rollback procedure with the provider first. A live pilot is not a practice scenario, and any real payment, guest communication or delivery must be handled deliberately rather than triggered accidentally.
Turn gaps into an operational decision
Some menus contain choices inside choices: for example, an extra protein followed by a required preparation choice. Ask the provider to show how that exact structure appears in your marketplace, POS and kitchen output. If it cannot be represented as needed, record it as a limitation rather than treating an unsupported case as a failed promise.
Then choose a fallback. You might simplify the menu, make the nested choice a separate clearly named option, or have a designated staff member check the marketplace order and enter an instruction manually. Each fallback changes the work at the counter. Check whether it remains practical during a busy shift and whether the POS price and kitchen instruction still agree.
For each unresolved row, name one owner and a decision date. The provider might own a mapping demonstration; your menu manager might own a simplified option; your shift lead might own the manual check. Define the decision as well: approve the connection for that channel and location, approve it with a documented manual step, or hold it until the gap is resolved.
Do not let a partial pass become a blanket approval. If the priced add-on arrives correctly but the required base is missing from the kitchen ticket, the bowl is not ready for normal service under your stated requirements. If all selections and totals match but a rare nested choice needs a workable manual check, the owner can decide whether that limited workload is acceptable.
Compare the connection you will actually use
When discussing restaurant integrations, give each provider the same order cases and ask for the exact marketplace, location and POS combination. Ask which connections are available now, which require a request, and what setup or manual steps are involved. For example, Fleksa's integration directory distinguishes live connections from those available on request; its Toast and Square POS connections are listed on request.
Ask to see the order in your intended restaurant POS system and on the kitchen output, not just in an order-management screen. Otter describes an order manager that consolidates online and manual orders, supports automatic acceptance and printing, and connects to POS systems. For either approach, the useful question is whether your particular modifier cases reach the tools your staff will use.
If Uber Eats is on your channel list, include it in the demonstration and review the Uber Eats integration information alongside your own acceptance sheet. Availability and setup depend on the restaurant. Ask for a written quote covering setup, recurring charges and any separately charged services, then compare those costs with the manual work each option leaves behind.
Next step: Bring your channel list, locations and completed test cases to a Fleksa demo. Ask the team to walk through each modifier journey and confirm availability for your restaurant's location.
Frequently asked questions
Does a mapped menu item guarantee its modifiers will arrive?
No. Check required choices, optional instructions, paid extras and quantities separately in the POS and kitchen output.
Should I use a real customer order for the test?
No. Start with a simulation that cannot charge a card, message a guest or dispatch a courier. Use a unique test identifier instead of customer details.
What if a nested modifier is unsupported?
Document the limitation and decide whether to simplify the menu or use an assigned manual step. Approve that fallback only if staff can carry it out reliably.
