Staff can distinguish brands and route orders correctly from a shared kitchen only if the order system preserves the brand, channel, and destination information your team needs at each step. A combined screen alone does not answer that question. Before buying, ask to see how an order moves from each channel account to your POS and kitchen, and what staff must do manually.
Start with a routing matrix, then use simulated orders to check the details that matter on a busy shift. Include similar items, simultaneous orders, and an order sent to the wrong destination. The goal is a workflow your team can explain and operate, not just a demonstration of a connected account.
Map brands, channels, and physical kitchens
List every brand customers can order from, every channel account attached to it, and every physical kitchen that prepares its food. Treat two storefronts on the same marketplace as separate accounts if they have separate menus or destinations. Also note direct-ordering sites, phone or manual orders, and any channels you plan to add soon.
For each account, record the menu, operating hours, intended POS location, and kitchen destination. One physical kitchen can prepare food for several brands, while one brand may operate from several kitchens. Do not assume the brand name alone identifies where an order should go.
The following example is hypothetical. Harbor Bowls and Ember Wraps share the East kitchen; Harbor Bowls also operates from a West kitchen. The matrix records intended routing, not a claim that a particular product supports it.
| Brand and channel | Physical kitchen | Expected POS and kitchen destination | Open question |
|---|---|---|---|
| Harbor Bowls: marketplace account A | East | East POS; East kitchen queue, labeled Harbor Bowls | Does the brand label reach the kitchen? |
| Ember Wraps: marketplace account B | East | East POS; East kitchen queue, labeled Ember Wraps | Can staff filter the queue by brand? |
| Harbor Bowls: marketplace account C | West | West POS; West kitchen queue, labeled Harbor Bowls | How is the West destination selected? |
| Ember Wraps: direct-ordering site | East | East POS; East kitchen queue, labeled Ember Wraps | Does this source use the same routing rules? |
Read each row as a separate route to verify. A successful result for account A does not establish that account C reaches the right location, even though both sell under Harbor Bowls. Add rows for temporary storefronts, catering channels, or other routes that affect your operation. If a destination depends on time of day or delivery area, record that rule too.
Give the completed list to each vendor before a demonstration. The restaurant integrations directory can help you identify connections to discuss; distinguish a connection listed as live from one listed on request. Availability and setup still need confirmation for your restaurant. For a specific marketplace, the Uber Eats integration page is a useful starting point, but ask about your actual accounts, locations, and POS combination.
Check what staff can see and control
Ask the vendor to follow one order from its source account through every screen or printed ticket the team will use. Can the cashier see the brand and source? Can the cook see the brand, destination, items, and modifiers without opening another screen? Can the expeditor identify which packaging belongs with the order?
Then ask how the view changes when several brands and locations are active. A filter can help a cook focus on one queue, but it also needs an obvious way to show that another queue is waiting. Ask whether staff can search by order identifier, see the physical location, and tell which orders need attention. Confirm whether a filter changes what appears on a kitchen display, a printer, or only the screen being viewed.
Separate automatic actions from manual work. If someone must select the brand, re-enter an order, or choose a printer, write down who does it and when. A manual step may be acceptable at low volume, but it needs a backup when that person is busy or absent. Ask what happens when an account is connected but its intended destination is unavailable.
Otter describes an Order Manager that consolidates online and manual orders on a tablet, with automatic acceptance and printing and POS connections. Those broad functions do not by themselves answer how your brands and locations appear. Ask for the same account-by-account demonstration you would request from any provider.
Also compare an aggregator with the connections available through your existing restaurant POS system. Ask whether the route requires another device, another login, or a separate kitchen workflow. The related buying guide covers that wider architecture decision; for this purchase, focus on whether each brand reaches the right staff with usable information.
Simulate similar items and simultaneous orders
Use a vendor-provided simulation or other confirmed non-live test environment. Before entering anything, verify that the exercise cannot charge a card, send a guest message, or dispatch a courier. Use invented names and unique test identifiers, not real customer information. If the vendor cannot provide a safe way to simulate a route, ask for a walkthrough and record that route as still needing verification.
In the hypothetical kitchen above, prepare two cases arriving at roughly the same time. One is a Harbor Bowls rice bowl with a no-onion modifier; the other is an Ember Wraps rice wrap with extra sauce. Their similar names make it easier to spot a mix-up. Give each case a different identifier and specify its source account, expected East destination, items, modifiers, and expected total.
For each case, match the source order to the POS result and the kitchen result using its identifier. Check that the brand label, location, item, modifier, and total agree with the expectation. Also check that the two orders remain distinct when displayed together. Record what actually appears beside the expected result; do not mark a case passed just because an order appears somewhere.
Include a second-location case for Harbor Bowls. Its expected destination is West, not East. If the vendor shows that a route requires staff to select the location manually, record that action as part of the result and ask how staff will know which location to choose. If a case is intentionally unsupported, document the limitation and decide whether a reliable manual workflow is acceptable.
Simulation checks configuration without affecting guests. A live service pilot is a separate decision: use real orders only after agreeing on the workflow, staff ownership, and how issues will be handled. Do not treat a clean simulation as proof that every live exception will be handled automatically.
Plan reporting, permissions, and recovery
Ask the vendor to show the reports your managers need, not just a combined sales total. Can they separate orders by brand, channel, and physical location? Can they identify canceled orders and adjustments in the view or export they use? Compare the report fields with the routing matrix so that a shared kitchen does not make two brands indistinguishable at closing.
Next, walk through permissions. Decide who may change a channel connection, menu assignment, routing destination, or user access. Ask how those permissions are set and whether managers can see who made a change. If the system cannot separate a particular duty, decide whether your operating procedures can compensate before accepting that limit.
For a wrong-brand or wrong-kitchen order, ask staff and the vendor to describe the recovery path. Who spots it? Can the order be moved or corrected, or must someone re-enter it? How does the kitchen know not to prepare a duplicate? Who checks the final POS record and contacts the channel or guest if a live order requires it? Practice the supported steps in simulation without sending a real message or dispatch.
Keep a short decision log next to the matrix. Assign each unanswered question to a named owner, set a date for an answer, and state the decision it affects. For example, the operations manager might own the question of whether East staff can filter by brand; if the answer is no, the next decision is whether a clearly labeled combined queue is workable. The POS administrator might own the West routing question and hold that connection out of rollout until its destination is demonstrated.
Before committing, compare written quotes for the software, setup, devices, support, and any channel or transaction charges that apply to your configuration. Ask which costs are fixed, which vary with volume, and which arise from exceptions or changes. A low software quote is less useful if it omits required equipment or manual work your team must cover.
Bring your channel list, routing matrix, and simulated test cases to a Fleksa integrations demo discussion. Ask Fleksa to confirm availability for your location and show the specific routes and recovery steps your team needs.
Frequently asked questions
Can two brands share one kitchen queue?
They may be able to, depending on the setup. Ask whether each order retains a visible brand label and whether staff can distinguish packaging, modifiers, and destination when orders arrive together.
Is a marketplace connection enough to prove brand routing works?
No. A connection is a starting point. Check each account with your POS and kitchen destination, including any manual selection staff must make.
What if a vendor does not support one of my routes?
Record the limitation and its operational effect. Decide whether a documented manual process is practical, whether another route should remain in place, or whether the missing route rules out the purchase.
