Staff can tell whether a delivery order was accepted, received and ready across a marketplace and POS only if they know what each status means and where to look for it. The same word can describe different events: a marketplace may show an order as accepted while the kitchen has not yet received a usable ticket.
Before choosing an integration, map each status to an action, trace one order through the exact channel and POS combination, and assign someone to resolve gaps. A connection that transfers orders may still leave staff checking a tablet or updating a status by hand.
Start with the action behind each status
Make a separate row for every marketplace, POS and restaurant location you need to support. Include the screens staff actually use, such as a marketplace tablet, a POS order view and a kitchen display or printer. A setup that works at one location does not answer whether the same setup is available at another.
For each screen, write down the status label and the event it represents. Ask the vendor to distinguish these milestones:
- Placed: The guest submitted an order. This alone does not tell the restaurant that it has received it.
- Accepted: Someone or something acknowledged the order. Find out which system made that decision and whether staff can decline it.
- Received: The order appeared in the restaurant system. Check whether that means it reached the POS, a kitchen screen, a printer or only an intermediary screen.
- Ready: The restaurant marked the food ready for pickup. Ask where that action is performed and which other screens, if any, receive the update.
- Picked up or completed: The order left the restaurant or was closed in a system. Ask who records the event and whether the other system changes automatically.
Labels alone are not acceptance criteria. For example, an order can be visible in the POS but still need a manual kitchen action. Likewise, a ready button may update the restaurant screen without changing the marketplace screen. Treat those as questions to resolve for your setup, not as assumed behavior.
The restaurant integrations directory can help you build a channel list. Check whether each connection is live or available on request, then confirm availability for your location and setup. A listed connection is a starting point for the status questions below.
Build a translation table for one order
The table below is a hypothetical example, not a description of any vendor's integration. Its labels and results are invented. It shows how a manager could compare the restaurant's intended workflow with what each screen reports.
| Milestone | Marketplace screen | POS or kitchen screen | Question or action |
|---|---|---|---|
| Order placed | New order | No order visible yet | How long should staff wait before checking? |
| Order accepted | Accepted | Order received | Does acceptance mean the kitchen has a usable ticket? |
| Food being prepared | Accepted | Preparing | Does the marketplace receive a preparation update? |
| Food ready | Accepted | Ready | Must staff also mark it ready on the marketplace tablet? |
| Order collected | Picked up | Ready | Who closes the POS order, if it does not close automatically? |
Read across each row, not just down one screen. In this example, the restaurant can see that food is ready in its kitchen view, but the marketplace still says accepted. That is a mismatch in visible status. It does not, by itself, prove that the order failed or that a courier was notified.
Add your own labels and expected actions before a demonstration. Mark each transition as automatic, manual, unavailable or still to be confirmed. Ask whether an update travels from the marketplace to the POS, from the POS to the marketplace, both ways or neither way. Direction matters: receiving an order does not necessarily mean a later kitchen update travels back.
If you are deciding between a direct connection and another integration layer, the related buying guide covers the broader choice. For this decision, focus on what staff can see and do at each order milestone.
Trace a safe order from placement to pickup
Ask the vendor to demonstrate the exact marketplace, POS and location combination you intend to use. Agree on the expected result at each step before starting. A demonstration of one channel does not establish the behavior of another.
Use a simulation or approved test environment that cannot charge a real card, send a guest message or dispatch a courier. Confirm those safeguards with the vendor before entering the order. Use a unique test identifier and no private customer data. If a safe environment cannot show a step, record that step as unverified and ask how it can be checked safely.
- Place the simulated order. Record its identifier, channel and location. Include an item with a modifier so you can match more than the order total.
- Check acceptance. Note whether acceptance is automatic or requires a person. Record the label and time shown on each available screen.
- Find the restaurant copy. Match the identifier to the POS and kitchen result. Check the item, modifier and total. Ask what staff should do if the order is accepted in one place but absent in another.
- Mark it ready. Use the supported action in the test environment. Compare the marketplace and restaurant labels, and record whether another manual step is needed.
- Represent pickup. If the safe environment supports a simulated pickup, compare the final statuses. If it does not, leave that transition unverified rather than treating it as passed.
For every step, write down the expected result and the observed result separately. A useful note might read: “Expected: ready appears on both screens. Observed: ready appeared in the kitchen view; marketplace remained accepted during the demonstration.” Add the time checked and the next action agreed with the vendor. That record is more useful than a general statement that the integration works.
Also ask to demonstrate supported exception handling: an order that cannot be accepted, a change or cancellation, and a missing or delayed restaurant copy. Do not assume every connection supports every case. An intentionally unsupported case is a limitation to plan around, not a failed test of a promised feature.
A live service pilot is different from a simulation. Arrange one only after confirming the normal order, payment, notification and delivery workflow with the providers and your staff. Do not use a practice scenario to create a real charge, guest message or courier dispatch.
Decide what happens when statuses disagree
A useful comparison includes the work left for your team. Ask how long an update normally takes, what alert appears when it does not arrive, and whether staff can retry an action. Agree on a practical check interval with the vendor rather than assuming that every screen updates instantly.
Then assign ownership by situation. For a small restaurant, one shift lead may own all three checks; a larger operation may split them:
- Accepted on the marketplace, missing from the POS: The shift lead checks the source order and follows the agreed recovery procedure. Ask which system is authoritative for the order details and how to avoid entering a duplicate.
- Present in the POS, missing from the kitchen: The kitchen lead checks the intended kitchen screen or printer and follows the restaurant's backup procedure. Decide who confirms that preparation has actually started.
- Ready in the kitchen, unchanged on the marketplace: The handoff lead checks whether a marketplace action is required. Do not assume that marking ready in one screen sent an update elsewhere.
Keep a short exception log with the test identifier or permitted order reference, the two statuses, the time checked, the owner and the next decision. Avoid storing unnecessary guest information. If the next step is unclear, the owner contacts the appropriate provider using the restaurant's support process.
Consider a hypothetical decision between two quoted setups for one location. Setup A meets the restaurant's required placement and receipt checks, but staff must mark ready on a separate tablet. Setup B has not demonstrated the required receipt check. If the team can reliably own the extra tablet step, A is the stronger choice on the stated evidence; B needs another safe demonstration before a decision. This is an operational comparison, not a claim about either provider's price or features.
Before signing, put remaining questions into the quote or implementation discussion: which transitions are included, which require staff action, what support handles a mismatch, and whether the same behavior applies at every location. A lower quote is less useful if it leaves a critical handoff without an owner.
Bring your channel list, translation table and test cases to a Fleksa demo. Explore the restaurant POS system and ask which status actions are available for your location and exact setup.
Frequently asked questions
Does accepted mean the kitchen received the order?
Not necessarily. Ask what triggers acceptance, then match the source order to the POS and kitchen result. Confirm that the items, modifiers and total are usable by staff.
Can staff update a marketplace order from the POS?
That depends on the channel, POS and connection. Ask the provider to show each supported action and whether the resulting status appears on both screens.
What if a status update is delayed?
Agree on when staff should check, who owns the mismatch and what recovery action is safe. Record the two screen labels and the time checked before contacting support.
