Yes, an integrated marketplace bundle can retain its components and total when it reaches a restaurant POS, but the result depends on the marketplace, connection, POS setup, and bundle configuration. The buying decision is whether your actual combination preserves enough detail for the kitchen and records the right amount on the check.
Do not stop at seeing the combo name on a screen. Match one marketplace order to its POS check and kitchen output. Confirm the component quantities, any choices, and the final total. Then make sure the bundle price and its component allocations are not both counted as sales.
Set requirements around your service workflow
Start with a bundle your restaurant sells often or expects to sell soon. Write down what the guest selects, what the kitchen needs to prepare, and how the order should appear on the check. A meal with a main item, two sides, and a drink is a more useful starting point than a single item with one option.
The owner or operating manager should own the buying decision. Include the person who manages the menu, the shift lead who handles delivery orders, and whoever reconciles POS reports. Each sees a different failure: a menu manager may spot a missing mapping, while a cook may notice that the ticket does not show how many sides to pack.
Define the exact scope before asking for a demonstration: location, marketplace, ordering device or tablet, connection method, POS, and kitchen display or printer. A result on one combination does not establish what will happen on another. Repeat the check for each combination that matters to the rollout, particularly if locations have different menus or equipment.
Also decide what a usable result looks like. Must the kitchen see the bundle name, every component, and the guest's selections on one ticket? Can staff work from separate component lines? Does the POS need allocated amounts on those lines for reporting? Those are operational requirements, not merely display preferences.
For context on connection choices, see the guide to direct POS integration and middleware. A direct connection and an intermediary can both be worth evaluating; neither label alone tells you how a particular bundle will map.
Compare the bundle parent and its components
A bundle has a parent identity, such as “Lunch Meal,” and component items, such as a burger, sides, and a drink. The parent helps staff recognize what the guest bought. The components tell them what to make and pack. A useful mapping needs both, whether they appear as a parent with nested lines or in another readable format.
Ask the vendor to show the order at three points: the marketplace source, the POS check, and the kitchen output. Use a unique test identifier to match them. Check the name and quantity of each component, not just the presence of a bundle line. Two sides should remain two sides even if the POS represents them as one line with a quantity of two.
Then check selections attached to the right component. For example, a no-onion request belongs with the burger, not the drink. If the guest chooses a drink flavor, the kitchen needs that choice as well as the drink quantity. Modifier mapping matters here, but it is only one part of the bundle check: correct choices do not compensate for a missing side or an overstated total.
Ask how menu changes are handled. If you rename a side, replace a drink, or change a component quantity, who updates the mapping and how is it verified? Find out whether an unavailable component blocks the bundle, requires a marketplace menu change, or needs staff intervention. Do not assume that a substitute will map correctly without checking it.
Fleksa's integration directory distinguishes live connections from those available on request. Availability depends on the restaurant's setup. Otter describes an Order Manager for consolidating online and manual orders, with automatic acceptance and printing and POS connections. For either option, ask to see the specific marketplace, POS, and bundle behavior you need; those general descriptions do not establish your result.
Simulate a bundle from source order to kitchen
The following is a hypothetical example, not a result from a vendor test. Suppose a marketplace meal costs $14 and contains one burger, two sides, and one drink. For this example, the POS allocates $8 to the burger, $2 to each side, and $2 to the drink. The allocations add up to $14: $8 + $4 + $2.
The $14 is the bundle sale amount in this example, not an operating-cost quote. It excludes fixed costs, variable costs such as processing or delivery charges, and exception costs such as staff time to correct a mapping. Assess those separately when comparing written quotes and workflows.
Agree on the expected result before the demonstration. The POS may show the $14 parent as the priced line and list components without adding their allocations again. Or it may use component allocations that add to $14 while treating the parent as a label. The display can differ, but the sale total must not become $28 because both the parent and all allocated components were added.
Use the worksheet below to record what to look for. The statuses shown are example decision labels, not observed test results. Replace them with the actual result for each configuration you evaluate.
| Check | Expected result | Decision and follow-up |
|---|---|---|
| Bundle identity | One Lunch Meal is recognizable on the POS check and kitchen output. | Pass if both are usable; shift lead confirms. |
| Components | One burger, two sides, and one drink reach the kitchen with the correct choices. | Fail if a quantity or choice is missing; menu manager investigates. |
| Amount | Sale total is $14; component allocations, if shown, add to $14 without another $14 charge. | Pass if the check and relevant report agree; reconciliation owner confirms. |
| Unsupported swap | Staff can identify the limitation and know what action to take. | Unknown until demonstrated; vendor explains the behavior and workaround. |
Run this first as a simulation in a safe test environment. Ask the vendor how to create the source order and follow it through the connection without a real card charge, guest message, or courier dispatch. If those effects cannot be disabled, use a vendor-provided demonstration instead of creating a live order. Record the unique identifier, configuration, expected result, observed result, and person responsible for checking it.
Have the shift lead read the kitchen output as if preparing the meal. Can they identify both sides and the drink choice without opening another screen? Have the reconciliation owner inspect the POS check and relevant report. If a manual edit is necessary, write down exactly who makes it and when. Do not mark a mapping as automatic if staff must repair each order.
A simulated check is not a live service pilot. If the simulation meets the requirements, plan any later pilot separately with the vendor and staff. Define the locations, hours, support contact, and fallback process. Protect guests from unintended charges or messages, and do not trigger a courier merely to practice. A pilot can reveal service conditions the simulation missed, but it does not guarantee uninterrupted service.
Decide what to accept, fix, or leave unsupported
Review the results by configuration rather than giving the integration one overall pass. A standard meal might pass while a meal with a swap remains unknown. An intentionally unsupported combination can be acceptable if you can remove it from the marketplace menu or handle it through a workable process. It should not quietly become a staff problem during a rush.
For every failed or unknown case, assign an owner and a next action. The vendor might need to explain a mapping or provide a configuration change; your menu manager might need to simplify the bundle. Set a retest date and repeat the source-to-POS-to-kitchen check after the change. Keep the original and retest results together so everyone can see what changed.
Before accepting a workaround, ask how often it will occur and what happens when the responsible employee is away. A shift lead might approve a rare manual correction during a limited pilot. An owner may reasonably reject the same correction for a popular bundle at every location. Document who can approve the exception and when it expires or must be reviewed.
Price allocation deserves its own sign-off. Ask how discounts, paid upgrades, and substitutions affect the parent amount and component lines. Check whether the relevant POS reports show the sale in the way your team expects. If a contract or the treatment of a transaction needs legal or tax interpretation, consult a qualified adviser rather than relying on a software demonstration.
Finally, compare the operational quote totals for the configurations you are considering. Ask vendors to identify fixed charges, variable charges, and likely exception work separately. A quoted processing fee alone is not the all-in cost of running the workflow, and a low quoted total may not account for manual corrections.
Bring your own sample bundle to a demo of the Fleksa restaurant POS. Ask the team to show the source order, POS check, and kitchen result for your marketplace and location, including the total and any unsupported case.
Frequently asked questions
Is a bundle name on the POS enough?
No. Staff also need the correct component quantities and choices, and the check needs the correct total. Confirm that the kitchen output is usable, not just that the parent name appears.
Should component prices add to the bundle price?
If the POS uses component allocations, they should reconcile to the intended bundle amount under the configuration being tested. Check that those allocations are not added a second time on top of the parent price.
What if a marketplace combination is unsupported?
Ask whether you can remove the combination, change the menu, or use a documented manual process. Assign someone to approve the workaround and retest if the setup changes.
