When two connected restaurant systems disagree, the vendor that receives your support request should own the initial investigation and coordinate the handoff, even if another company ultimately has to fix the problem. Agree on that responsibility before buying. A connection between products does not, by itself, tell you who will investigate it.
Start with a named first contact, then map who investigates each boundary: the source system, the connection, and the POS or kitchen destination. Put those assignments in writing alongside support hours, escalation contacts, and the information your staff must collect.
Identify every participant in the order path
An integration can involve more companies than appear on the sales quote. An online ordering system may send an order through a separate integration provider to a POS, which then routes it to a kitchen screen or printer. Each boundary is a place where the expected result can differ from what staff see.
List the participants for each location and ordering channel:
- Source system owner: The provider responsible for the system where the order starts, such as a direct ordering site or marketplace.
- Integration owner: The company responsible for configuring or operating the connection. This may be the source provider, the POS provider, or a separate vendor.
- POS provider: The company responsible for the receiving POS and its configuration.
- Other destination owners: Providers responsible for a kitchen display, printer, or other connected destination, if they are separate from the POS provider.
- Restaurant contact: The person who can report the issue, identify the location, and make operational decisions while it is investigated.
Do not assume the company that sold you the connection operates every part of it. Ask who maintains the mapping between menus, modifiers, and POS items, and who can investigate when that mapping produces the wrong result. Also ask whether the answer changes for a marketplace order versus an order placed directly with your restaurant.
For a comparison of connection approaches, use this guide to direct POS integration and middleware. Fleksa's restaurant integrations directory distinguishes live connections from connections available on request. Confirm the actual setup for each location and channel before relying on it.
Map incident ownership across the boundaries
The most useful distinction is between the incident owner and the vendor that fixes a particular fault. The incident owner is your first contact and remains responsible for coordinating updates. A specialist vendor may investigate or correct a problem in its own system. Neither assignment should depend on your staff proving where the fault began.
The following matrix is hypothetical. It assumes an ordering provider agrees to act as first contact, a separate integration vendor operates the connection, and a POS provider owns the receiving system. These are example assignments, not promises about any provider. Change the names and responsibilities to match your agreements.
| What staff see | First contact and handoff | Evidence to collect |
|---|---|---|
| Order appears in the source system but not the POS | Ordering provider opens the incident; integration vendor checks transfer; POS provider checks receipt if needed. | Location, source order ID, time, and whether the order is visible in the POS. |
| Order arrives, but a modifier or total differs | Ordering provider coordinates; integration and POS vendors check the relevant mapping and received details. | Order ID and source and POS versions of the affected items, modifiers, and total. |
| Order appears in POS but not at the kitchen destination | Ordering provider coordinates; POS and kitchen destination owners investigate routing and output. | Order ID, POS status, affected kitchen device, and time observed. |
| Cancellation or another exception differs between systems | Ordering provider coordinates with the vendors responsible for the supported exception path. | Order ID, requested action, time, and the status shown in each system. |
Read the matrix from left to right: start with the symptom, call the agreed first contact, and provide the evidence listed. The first contact should tell you who has accepted the next investigation step and when to expect an update. A support ticket number is useful, but it is not a substitute for an agreed owner.
For each handoff, ask what happens if the receiving vendor cannot find the transaction, disputes the diagnosis, or does not respond. Decide who follows up and how your restaurant escalates an unresolved incident. Also name a backup contact for the hours when the primary contact is unavailable.
Evidence should be specific enough to find one transaction without sending unnecessary guest information. Ask vendors which identifiers and screenshots they need and how to share them securely. Staff should not send card details or passwords in an ordinary support message.
Test the handoff with a missing-order scenario
Before accepting the connection, walk vendors through a simulated missing order. Use a designated test environment or another vendor-approved method that cannot charge a real card, send a guest message, or dispatch a courier. Confirm those safeguards before starting. A conversation about the scenario is useful; observing the agreed workflow in a safe simulation is better.
- Create or use one test order with a unique reference ID. Include an item and a modifier that matter to your menu, along with the expected total.
- Ask the first-contact vendor how staff would report that the source order is visible but the POS result is missing. Provide the test ID, location, and time.
- Have the vendors explain or demonstrate how they would trace that ID across the source, connection, and POS. Ask what evidence would establish whether each system received or passed the order.
- Ask who contacts the next vendor, what information is included, and who updates the restaurant while the investigation continues.
- Match the test source order to the POS and kitchen result where the test setup permits. Check the item, modifier, and total, not just whether an order appeared.
- Review the supported exception paths, such as cancellation, and identify any limitations. An unsupported case should be recorded as a limitation, not treated as a failed promise.
Set acceptance criteria before the walkthrough. For example, the first contact should identify the next investigator and explain how the restaurant receives updates. The order details should match across the agreed test path. If a vendor cannot demonstrate a step safely, record what remains unverified and agree on how it will be checked.
A simulation is different from a live service pilot. If you later choose a live pilot, plan its scope, staff coverage, and fallback procedure separately with the vendors. Do not assume a practice order proves that every live channel, device, or exception will behave the same way.
Capture commitments before signing
Turn the matrix into an attachment or other written record that the relevant providers accept. A salesperson's general assurance that a connection is supported leaves too much room for disagreement during a busy service.
Ask each provider to document:
- Coverage: Which locations, order sources, POS versions, devices, and exception paths are included?
- First contact: Which team receives a cross-system incident, and through which channel?
- Support hours: When can you report an issue, when is investigation available, and what happens outside those hours?
- Handoffs: Who contacts another vendor, shares the incident reference, and remains responsible for updates?
- Escalation: Who is the backup contact if the first team cannot make progress, and when can you use that route?
- Exclusions and changes: Which configurations or changes require separate work, and who must approve or pay for it?
Use written quotes to compare the support and setup work included by each provider. Ask about charges for configuration changes, troubleshooting outside support hours, and work involving another vendor. A low connection charge may not be the lowest operational quote if the help you need during service is excluded. Ask a qualified adviser about contract or legal treatment where appropriate.
Consider a practical choice: one provider offers a connection but expects the restaurant to contact each vendor separately; another agrees in writing to coordinate incidents across the same systems. If the quoted scope and support hours otherwise meet your needs, the second arrangement gives staff a clearer path when an order goes missing. It does not guarantee a faster fix, so compare escalation terms and exclusions as well.
Finally, give shift leads a short version of the matrix: the first support contact, the information to collect, and the restaurant's fallback procedure. Review it whenever you add a channel, change a POS, or move responsibility to a new provider.
Ready to put ownership in writing? Bring your order path and missing-order scenario to a provider discussion. Review the Fleksa restaurant POS and ask who would investigate and coordinate each handoff for your setup. You can also review common integration questions before the conversation.
Frequently asked questions
Who should I call first when an order is missing from the POS?
Call the first contact named in your support agreement. Give them the location, source order ID, time, and what staff can see. They should coordinate the next investigation rather than leave your team to identify the fault.
Does the POS provider always own an integration failure?
No. The cause may sit in the source system, the connection, the POS, or a destination such as a kitchen device. Agree in advance which provider coordinates the incident and which providers investigate their respective systems.
What if a vendor says another company caused the problem?
Ask your incident owner to share the relevant reference and evidence with that company, confirm who accepted the handoff, and give you an update time. Use the agreed escalation contact if ownership remains disputed.
