Before routing a new delivery channel into service, confirm that the right restaurant location and accounts are connected, the menu and order actions work as needed, and an order reaches the intended kitchen or POS with the right details and total. Assign someone to handle exceptions and know who to call when an order does not appear.
A connection shown in a vendor directory is a starting point, not a service-ready setup. Check the exact marketplace, restaurant location, POS, and actions you need. The difference between receiving an order and being able to manage it during a busy dinner can be substantial.
Start with accounts and location identity
List each marketplace and restaurant location separately. A restaurant with two storefronts may have different marketplace accounts, menus, hours, and POS locations for each. Do not assume that access granted for one address covers the other.
For each location, identify the person who can authorize the marketplace account and the person who administers the aggregator and POS. Ask what permissions are needed, who must approve the connection, and whether an existing marketplace tablet or workflow must remain active during setup. Use staff access controls rather than sharing personal passwords.
Check the location name, street address, marketplace store identifier, and destination POS location together. Similar storefront names are easy to confuse. A manager should be able to point to the exact destination where that store’s orders are expected to appear.
Then ask the vendor to confirm availability for that combination. Fleksa’s restaurant integrations directory distinguishes live connections from those available on request. The Uber Eats integration page is another place to start a channel-specific conversation. Availability still depends on the restaurant’s setup. Toast and Square POS connections, for example, are listed on request; ask whether the needed connection can be provided for your location.
Put unknowns in writing before agreeing to a launch date. Useful questions include: Who creates the connection? Is marketplace approval required? Can the existing channel remain open during setup? What must the restaurant do if approval takes longer than expected?
Map the menu and agree on supported actions
Ask where the menu starts and how changes reach the marketplace. Does the connection import an existing menu, send a menu outward, or require staff to maintain some items separately? Have the provider show the workflow for the exact channel and POS combination, rather than relying on a general integration demonstration.
Check a small set of items that represent the real menu: a standard item, an item with required choices, an optional paid add-on, and an unavailable item. Compare names, prices, modifiers, availability, and location-specific hours. If the marketplace and POS use different names for the same item, confirm how staff will recognize it on the kitchen ticket.
Make a separate action list. Receiving an order is one action; accepting it, adjusting preparation time, canceling it, marking an item unavailable, and handling a refund are others. Ask which actions are supported through the connection and which require the marketplace portal or tablet. Also ask where changes made in one system appear in the others.
Manual work is not automatically a reason to reject a connection. It becomes risky when no one owns it. If an out-of-stock item must be disabled in the marketplace portal, name the shift role responsible and make sure that person has access. If an action is unsupported, record the limitation and the fallback rather than treating it as a failed test.
Ask for an operational quote that separates setup and recurring charges from any per-order or exception charges. Confirm what is included and what the restaurant pays separately. Processing fees alone are not the all-in cost of running a channel; marketplace, delivery, support, and other charges may also matter. Compare written quotes for the same locations and expected workflow, and ask a qualified adviser about contract or tax treatment when needed.
Use a safe order scenario to check the route
The following example is hypothetical. It is a worksheet for planning a simulation, not a claim that a test was performed or that any particular provider supports the actions shown.
Suppose a restaurant wants a new channel to send orders to its East location. The sample order, identified as TEST-EAST-17, contains a $12 sandwich, a $2 cheese modifier, and a $3 side. The expected item total is $17. A $4 delivery charge makes the displayed order total $21. This example includes those item and delivery amounts only; it excludes tax, tips, discounts, processing charges, and other fees. The $21 is an order total, not the restaurant’s payout or operating cost.
Before running anything, agree on a vendor-supported simulation or sandbox that cannot charge a real card, send a guest message, or dispatch a courier. Use invented customer details. If the provider cannot offer a safe simulation, review a non-transmitting demonstration and agree on a separate live-service plan before launch. Do not send a practice order into the live channel just to see what happens.
Match the unique identifier from the source view to the intended POS or kitchen destination. The worksheet below shows what the East location’s owner would check. “Pending” means the result still needs to be observed and recorded in the safe environment.
| Check | Expected result | Observed result | Owner and decision |
|---|---|---|---|
| Location and identifier | TEST-EAST-17 reaches the East destination | Pending simulation | Manager confirms destination before launch |
| Items and modifier | Sandwich, cheese modifier, and side are visible to the kitchen | Pending simulation | Kitchen lead checks the displayed details |
| Amounts | $17 items plus $4 delivery equals $21 displayed total | Pending simulation | Manager compares source and destination; asks how delivery appears if omitted |
| Exception | A supported rejection or cancellation follows the agreed workflow | Pending simulation | Provider and manager document the result or manual fallback |
The amount check needs context: the kitchen may not need every charge on its ticket. Ask where the full total should appear and which amounts should reach the POS. Record the expected fields for that setup before comparing results. A missing delivery charge on a kitchen ticket is not necessarily a mismatch; an unexplained difference in the agreed order view is.
Also check what happens when the destination is unavailable or an order cannot be accepted, if those exception paths are supported in the simulation. Who sees an alert, where does it appear, and what should staff do next? If a case is intentionally unsupported, document the limitation and manual route instead of marking it as a defect. Avoid storing guest names, addresses, or payment details in the worksheet.
Set a first-service plan and a decision owner
A passed simulation is useful, but live service adds staff handoffs and timing pressure. Treat the first live period as a separate, monitored launch. Choose a shift when a manager can watch the new channel without leaving the kitchen short-handed. Tell staff which orders should arrive through it, where to find them, and which system remains the fallback.
Give one person responsibility for watching the channel and another authority to pause or change the launch plan if the agreed route does not work. Write down support contacts for the marketplace, aggregator, and POS, including their available hours and the account information needed to open a case. Agree which provider handles a missing order and how the restaurant should reach the others if the issue crosses systems.
For the first live orders, compare the channel’s order identifier and item details with the intended destination using the restaurant’s normal, authorized access. Keep an incident log with the time, location, affected step, action taken, and support case number. Follow the provider’s instructions for handling an actual order; do not create real payments, guest messages, or courier dispatches merely for practice.
Set a decision rule before opening the channel. For example: proceed when account authorization, location mapping, menu checks, and the agreed safe simulation are complete, and every unsupported action has an accepted owner and fallback. Hold the launch if the order destination is uncertain or staff cannot identify how to handle a missing order. If menu updates are manual but the shift lead has access and a documented routine, the restaurant may decide that limitation is manageable.
Keep the worksheet after launch. Review unresolved items with their owners and set a date for each next decision. A new menu, second location, or POS change can alter the workflow, so repeat the relevant checks before expanding the connection. For broader architecture questions, compare a direct POS integration with middleware and review the requirements of your restaurant POS system.
Next step: Bring your location and channel list, required actions, and sample test cases to a Fleksa demo. Ask the team to confirm availability for your restaurant’s location and show how the proposed order route and exceptions would work.
Frequently asked questions
Does a listed integration mean my location can use it?
Not necessarily. Confirm the marketplace, location, POS, account permissions, and required actions together. Some connections are available on request, and setup can vary.
Should I run a real order before launch?
Start with a safe simulation that cannot trigger a real card charge, guest message, or courier dispatch. Plan the first live service separately, with staff monitoring actual orders and a documented fallback.
What if the connection cannot handle an action we need?
Ask whether staff can perform it in the marketplace portal or another existing workflow. Assign an owner and decide whether that manual step is acceptable before routing orders into service.
