Staff can resolve an order problem without assuming customer data is available, but only if they know the permitted contact path for that order and what to do when it fails. A name or phone field on a POS ticket is not a contact plan. The next step might be a channel-provided contact tool, a marketplace support route, or a manager’s decision about the order.
Before buying a delivery integration, map that path for each channel and location. Then ask the provider to show staff where the action starts, what happens next, and which problems still require manual work.
Start with the problems staff need to solve
Write down the delivery channels each location actually uses, along with its POS and any separate channel tablets. A restaurant with two locations may use the same marketplace at both but have different equipment, permissions, or support arrangements. Treat each channel, location, and POS combination as a separate item until you know the contact process is the same.
Next, list the situations that can stop or change an order. Useful examples include:
- An ingredient is unavailable and the kitchen needs a substitution decision.
- A modifier is unclear or conflicts with another instruction.
- The delivery address appears incomplete.
- The order is ready, but staff need help resolving a pickup issue.
- The guest reports a missing item after the order has left.
Not every problem calls for a direct message to the guest. A pickup problem may belong with the channel or courier support team. A missing-item complaint may need a manager to follow the channel’s resolution process. For an unavailable ingredient, the first question is whether the restaurant can ask the guest about a substitute at all.
For each situation, record who needs an answer, how quickly the kitchen needs a decision, and who can authorize the next step. Mark the contact method as unknown until someone can demonstrate it for that setup. Do not assume that because an order arrives in the POS, guest contact details or messaging controls arrive with it.
It also helps to separate the restaurant’s direct-order process from its marketplace process. Staff may see different information and use different tools depending on where the order began. A single kitchen workflow can still have several contact paths.
Compare the contact action, not just the data field
For each channel, ask the integration provider and, where needed, the channel operator to walk through a specific order problem. The useful answer is an action staff can take: where they open the order, which button or support route they use, and what they should do if that route is unavailable.
Ask these questions for the exact location, channel, and POS combination:
- Can staff initiate contact from the POS, or must they switch to a channel tablet or another screen?
- Does the order show a contact method, a masked number, a messaging option, or no guest contact option?
- Who can use the method, and does access change after pickup or order completion?
- Can staff contact channel support from the order, and what order reference will support need?
- Does the integration pass any response back to the POS, or must staff check and record it elsewhere?
- If a contact attempt fails, what status or error can staff see?
These are questions to demonstrate, not a checklist of features every provider should offer. A masked number, for example, is useful only if the right staff member can find and use it at the moment a decision is needed. A visible number is not the same as an integrated messaging workflow.
Mark each step as supported in the system, manual, or unresolved. A manual step is not automatically a deal-breaker. Switching to a tablet may be workable at one location, but a tablet kept in a manager’s office may slow down a busy kitchen. Include that staff movement in the decision.
Compare the setup against your current process, too. Fleksa’s restaurant integrations directory distinguishes live connections from those available on request. Availability depends on the restaurant’s setup. If you are considering a different connection method, the direct integration and middleware guide can help frame that choice; it does not replace checking the contact path.
Walk through a sample order safely
Use a simulation before considering a live service pilot. The following example is hypothetical; the names, order details, and results are invented. Configure the exercise so it cannot send a guest message, charge a card, or dispatch a courier. A paper walkthrough or a provider’s isolated demonstration environment can work if those safeguards are in place.
Sample order TEST-47 is for a chicken bowl with no onions and an extra sauce. The kitchen discovers that the sauce is unavailable. The expected result is that the order appears in the POS and kitchen view with the identifier, modifier, and total matching the source order. Staff then find the permitted way to seek a substitution decision, or follow the fallback if there is no contact route.
Give the person taking the exercise the role they would have during service. Do not tell them which screen to open. Ask them to explain their next action, the reference they would use, and where they would record the outcome. A manager can observe without taking over.
In this hypothetical walkthrough, suppose the order and modifiers match, but the staff member cannot find a contact action in the POS. They identify a channel tablet as the next place to look, but cannot determine whether it permits a guest message. Record the order transfer as matching in the exercise and the contact method as unresolved. Do not mark the contact test as passed just because the order appeared.
Use a short record for each case:
- Identify the location, channel, POS, and sample order reference.
- Write the expected kitchen result and contact action before the walkthrough.
- Record what the participant actually found or did in the simulation, without real guest data.
- Assign an owner and a date for resolving any missing step.
Repeat with a second problem, such as an unclear address, because its escalation route may differ. Also ask the provider to demonstrate supported exception handling, including what staff see when an action cannot be completed. An intentionally unsupported case is a documented limit, not a failed promise that every integration must handle it.
A live service pilot is separate from this simulation. If you choose one, set its scope and escalation coverage with the provider and channel first. Use the restaurant’s normal authorized processes for real orders, and make sure staff know when to hand an unresolved issue to a manager.
Give every contact gap a fallback owner
The matrix below shows how a restaurant could assign actions for four hypothetical problems. The routes are examples to verify, not claims that a particular channel provides them. Replace each conditional route with the demonstrated process for your setup.
| Problem | First permitted path to check | If unavailable | Owner and next decision |
|---|---|---|---|
| Ingredient unavailable | Channel guest-contact tool, if available | Contact channel support; hold the affected preparation while awaiting direction | Shift manager decides the next order action under the channel process |
| Unclear modifier | Guest-contact route for that order, if available | Escalate to channel support rather than guess | Kitchen lead alerts the manager before preparation proceeds |
| Incomplete address | Channel order or support screen | Ask channel support to advise on delivery details | Shift manager decides whether the order can proceed |
| Pickup issue | Channel courier or support route, if available | Escalate through the channel’s support process | Shift manager tracks the order and decides when to seek further help |
Keep the completed matrix where staff handle orders. Add the actual support route and the order reference staff need for each channel. If a route requires a manager login, say so. If the restaurant must wait for the channel to make a decision, say who watches for the response and how the kitchen is informed.
Unresolved items need named owners beyond the shift. For example, the operations lead can ask the channel how substitution requests are handled, while the POS administrator asks the integration provider whether the contact action is available on the restaurant’s configuration. Set a decision date: either document the demonstrated path, accept the manual workaround, or exclude that setup from the purchase decision until the gap is resolved.
Review the matrix when a location changes its POS, adds a channel, or changes who handles the tablet. Train new staff on the route and the fallback, not on memorizing a guest-data field that may not appear.
Next step: Bring your channel list, POS details, and two sample problems to a Fleksa demo. Ask the team to walk through the permitted contact path and fallback for each location, and confirm availability for your setup. Start with the Fleksa restaurant POS system or review the Uber Eats integration before the conversation.
Frequently asked questions
Does a delivery order in the POS include the guest’s phone number?
Do not assume it does. Ask the channel and integration provider what staff can see and use for your exact setup, including any limits on access.
What should staff do if they cannot contact the guest?
Use the documented channel support route and alert the designated manager. The manager should follow the channel’s process for deciding what happens to the affected order.
Can we check the workflow without contacting a real guest?
Yes. Use a paper walkthrough or an isolated demonstration configured to prevent real messages, card charges, and courier dispatch. Record what staff found and resolve gaps before a separate live pilot.
