One tablet can be a practical home for supported delivery orders, but you should not retire your channel devices until you know which actions staff can complete there. Receiving an order is only the beginning. Acceptance, cancellation, changes and other exceptions may follow different paths for each channel and location.
Fleksa lists Uber Eats, DoorDash and Grubhub among its US marketplace integration examples. Availability depends on the restaurant’s location and setup. That is not a promise that every marketplace or every action can be handled on one device. Bring your actual channel list to the vendor and ask for a demonstration of the tasks your staff perform during a shift.
Start with channels, devices and shift actions
Make a separate list for each restaurant location. A channel used at one store may not be active at another, and a different POS setup can change the questions you need to ask. Include marketplace orders, direct online orders and any other source staff currently monitor. Note where each order first appears and where the kitchen expects to see it.
Then list the physical devices in use: marketplace tablets, the POS terminal, a shared tablet, printers and any kitchen display. One screen may show an order while another device remains necessary for an action. Your buying decision should cover the whole path, not just the number of screens on the counter.
For each channel, ask the shift lead which actions happen in normal service and which happen when something goes wrong:
- See a new order and recognize which channel sent it.
- Accept or reject it, where that choice is offered.
- Check items, modifiers, pickup timing and the amount shown.
- Send the order to the POS or kitchen and confirm it arrived.
- Handle an item change, cancellation or other channel-specific request.
- Find the right support contact when staff cannot complete an action.
Mark each action as confirmed, manual, unavailable or still to be demonstrated. A vendor’s channel list is a starting point, not a completed action list. Fleksa’s restaurant integrations directory distinguishes live connections from those available on request. Ask about the status for your location, POS and channels before planning a device change.
Build a device-and-action coverage matrix
The following is a hypothetical example for one location. The restaurant uses three marketplace channels and wants one shared tablet to reduce counter clutter. The entries are decision notes, not claims about Fleksa or any channel’s actual behavior.
| Channel and action | Shared-tablet expectation | Decision or fallback | Owner |
|---|---|---|---|
| Uber Eats: receive and accept | Show the order and its acceptance status | Keep channel access until both are demonstrated | Shift lead |
| DoorDash: modifiers to kitchen | Match the source order to the kitchen result | Resolve any mismatch before relying on the new path | Kitchen lead |
| Grubhub: cancellation | Show where staff must act and what status they can see | Keep a channel device or other confirmed channel access if needed | Manager |
| Local channel: new order | No shared-tablet connection assumed | Continue monitoring its existing device; ask about availability | Owner |
The matrix makes the decision visible: the hypothetical local channel still needs its existing device, while the three marketplace rows need demonstrations before the owner can change the setup. The owner column assigns follow-up work; it does not mean those actions have been confirmed. Add rows for every action your team uses, including rejections, changes and support escalation.
Be precise about the result you need. “Handles cancellations” could mean staff can initiate one, see that a channel canceled an order, or simply receive a notification. Ask the vendor to show the exact action and the resulting status. If staff must switch to a marketplace app or contact channel support, write down that step and identify the device or login required.
Also ask what happens when an order is already accepted on another screen. Can staff tell which action has been completed? Who sees the change? Do not assume the answer is the same across channels. If an action is unavailable, decide whether its frequency and fallback are acceptable rather than counting the integration as either perfect or useless.
Trace acceptance and exceptions to the kitchen
A good demonstration starts with the source order and follows it through every screen your staff use. Ask the vendor to show your exact channel and POS combination, not just a generic order arriving on a tablet. Fleksa lists Toast and Square POS connections on request; confirm whether the connection you need is available for your location and how it would be set up.
For an ordinary order, look for the channel name, order identifier, items, modifiers and total. Then follow the order to the restaurant POS system or kitchen destination used at your location. Match one source order to one result. Ask how staff would spot a missing or duplicate order before preparing food twice or overlooking a ticket.
Next, walk through exceptions that matter to your operation. Ask what staff can do when an item is unavailable, an order needs to be rejected, or a cancellation arrives after the kitchen has started. Identify which screen shows the current status and whether staff must take an additional manual step. If the vendor cannot demonstrate a particular action, leave it unresolved in the matrix and keep the existing method until you have an answer.
Timing matters too. A shared screen that staff check only after an alert on another device has not yet removed the need to monitor that device. Ask what signals a new order, how the team distinguishes channels and what happens if nobody responds. Have the vendor demonstrate the behavior rather than relying on a feature name.
Compare other approaches against the same action list. Otter describes a tablet for consolidated online and manual orders, automatic acceptance and printing, and POS connections. Those descriptions do not establish that your particular channel, POS and exception workflows will work as needed. Ask for a demonstration and a written quote for your setup.
Simulate a shift before changing devices
Use a controlled simulation for each supported channel. Arrange it with the vendor so that no real payment, guest message or courier dispatch can occur. Use fictional order details and a unique test identifier. Do not enter private customer information. If the vendor cannot provide a safe way to exercise a step, use a walkthrough or hypothetical record and mark the result as not observed.
For the hypothetical restaurant above, a shift lead could prepare three distinct cases: an Uber Eats order with a drink modifier, a DoorDash order with an item substitution request, and a Grubhub cancellation scenario. These are practice cases, not evidence that any action is supported. Before starting, the team writes the expected outcome and identifies the screen on which it expects to see each step.
- Start at the source. Assign each case a different identifier. Record the channel, items, modifier and displayed total for each simulated order.
- Check the shared screen. Record whether the order appears, which status is shown and whether the intended acceptance or rejection action is available.
- Follow the result. Where a safe test path exists, match the identifier, items, modifiers and total to the POS or kitchen result. Record any manual step.
- Try the exception. In the controlled environment, ask the vendor to demonstrate the relevant change or cancellation. Record what staff can do and where they must go next.
- Compare expected and observed. Mark each case as demonstrated, mismatched, unavailable or not observed. Assign an owner and a next decision to every open item.
For example, if the fictional drink modifier appears on the shared screen but not on the kitchen result, the case is a mismatch. The team should not call that path ready merely because the order arrived. If cancellation cannot be simulated safely, mark it not observed and retain the current cancellation procedure until it is demonstrated or otherwise confirmed.
A simulation is different from a live service pilot. After the safe checks, a manager may choose a limited live pilot during an actual shift, with staff monitoring the existing channel devices and following normal order procedures. Agree in advance on who watches each screen, how long the pilot runs and what triggers a return to the old workflow. Do not send artificial orders into live service as practice.
Set a fallback and make the device decision
Keep a channel tablet or another confirmed way to access the channel whenever the shared setup does not cover a necessary action. That may be because the channel is unsupported at your location, an exception requires channel access, or the team has not yet demonstrated the workflow. A device can move off the counter only after someone has decided how staff will handle those cases without it.
Write a short fallback beside the coverage matrix. Name the person responsible for checking the original channel, the device and login location, and the point at which the shift lead calls a manager or channel support. Keep access instructions available to authorized staff without posting passwords in the kitchen. Include a plan for a shared-device outage as well as for a channel-specific exception.
Set a review date for unresolved rows. The owner can then choose among three outcomes: retain the existing device, accept a documented manual step, or repeat the demonstration after the vendor confirms a change. This turns “we think one tablet should work” into a decision the next shift can follow.
For a broader comparison, see the related buying guide. For a channel-specific discussion, review the Uber Eats integration page. Bring your channel list, matrix and safe test cases to a Fleksa demo, and confirm availability for each restaurant location.
Frequently asked questions
Can I remove every marketplace tablet?
Not necessarily. Keep access to any channel or action that the shared setup does not cover, and retain a fallback until the workflows your staff need have been demonstrated.
Does a channel integration mean staff can cancel orders on the shared tablet?
Do not assume it does. Ask the vendor to show whether staff can initiate a cancellation, see its status or must use another channel device or support route.
How do I check that an order reaches the kitchen correctly?
In a safe simulation, give the source order a unique identifier and match it to the POS or kitchen result. Compare items, modifiers and the displayed total, and record any mismatch or manual step.
