Orders may keep reaching the right restaurant after a marketplace changes a store’s visible name, but a matching name is not enough to prove it. The decision depends on which location identifier the marketplace and integration use, whether the connection remains authorized, and where the resulting order appears. Ask the provider to demonstrate that path for each affected channel before approving the change.
This is a different question from setting up routing across multiple shops. You may already have the right locations connected. The risk here is that a new label hides a changed identifier, breaks a mapping, or makes staff mistake one location for another.
Set the requirements before the rename
Start with the person accountable for receiving marketplace orders at the affected restaurant. That might be the owner, an operations manager, or a location manager. Give that person authority to accept the result or stop the rollout. The person who can change marketplace settings and the person who manages the restaurant POS should also be involved; they may not be the same person.
Write down the current store name, address, marketplace channel, receiving device, POS location and kitchen destination. Include any middleware or order-management service between the marketplace and the POS. If the restaurant has several locations with similar names, list the neighboring locations too. A successful result must show that the intended restaurant receives the order and that it does not appear at a neighboring shop.
Agree on what is changing. Is it only the name guests see, or will someone also create a new marketplace listing, change an account, or reconnect a channel? A replacement listing can have a different identifier even if its address and new name look familiar. Treat that as a separate mapping decision, not as proof of a simple rename.
Decide when the check matters. Run it before signing if the integration is part of a purchase decision. Run it again before a planned rename goes live, and after any later reconnection or listing replacement that could affect the order path. If a safe simulated check is unavailable, agree with the providers on a controlled live-service pilot and its safeguards before changing the name.
Map identifiers separately from display names
A display name tells a guest or employee what to call a store. A location identifier is a value a system may use to distinguish that store from another. The exact fields and labels vary by provider. Ask each provider which identifier its connection uses and whether that identifier remains unchanged during the proposed rename. Do not assume an identifier is stable merely because a screen calls it a store ID.
Map the whole path: marketplace listing, integration connection, POS location, and the kitchen screen or printer staff actually use. Record both the identifier and the label at each point, where available. An address is a useful cross-check, but it should not substitute for knowing how the connection selects a destination.
The following is a hypothetical rename at one restaurant. The values are illustrative, not claims about any product. The expected result assumes the marketplace listing identifier remains M-418 and the existing mapping to POS location P-27 stays authorized.
| Point in order path | Before rename | Expected after rename | What to verify |
|---|---|---|---|
| Marketplace listing | Harbor Grill; M-418 | Harbor Kitchen; M-418 | New guest-facing name; same listing identifier |
| Integration connection | M-418 mapped to P-27 | M-418 still mapped to P-27 | Mapping and channel authorization remain active |
| POS location | Harbor Grill; P-27 | P-27 receives the order; displayed label may need updating | Destination identifier and label seen by staff |
| Kitchen destination | Harbor kitchen screen | Same intended kitchen receives the order | Ticket contents and absence at the neighboring shop |
The table separates a changed name from a changed destination. It also leaves room for the POS label to remain old: that may not misroute an order, but it can confuse staff. Ask who updates that label and when. If the marketplace instead creates listing M-419, the expected mapping above no longer applies. Obtain and check the new mapping before accepting orders through it.
Repeat the map for every marketplace in scope. Fleksa’s integration directory distinguishes live connections from connections available on request. Examples listed for the US include DoorDash, Uber Eats and Grubhub, subject to restaurant setup and availability. Ask about your specific marketplace, location and POS rather than assuming a listing covers every combination.
Run a safe acceptance check
Ask the marketplace and integration providers for a simulated order path that cannot create a real card charge, guest message or courier dispatch. Confirm those safeguards before anyone starts. A staff training exercise that only shows sample screens can teach the workflow, but it does not establish that a marketplace order will pass through the actual connection.
For the hypothetical Harbor rename, prepare a simulated source order with a unique identifier, such as TEST-HARBOR-01. Include an item, a modifier and a total that the receiving team can recognize. Record the expected marketplace listing, integration mapping, POS location and kitchen destination from the table before running the check.
- Confirm that the simulation is tied to the renamed listing and that it will not trigger payment, guest communication or dispatch.
- Have the marketplace or integration operator submit the simulated order using the agreed test identifier.
- Have the restaurant operator find that same identifier at the POS and kitchen destination. Check the item, modifier and total against the source order.
- Check the neighboring location for the same order, using the provider’s safe method. Record whether it appears there.
- Save the actual observed result, time, destination and responsible person. Compare them with the expected result rather than assuming that a changed label means the check passed.
If the provider offers a supported way to simulate an exception, agree on one relevant to the restaurant. For example, ask what staff would see if the destination connection were unavailable and how they would know an order needs attention. Do not disable a live connection during service just to create an exception. If that scenario is not supported in simulation, record it as unknown or as a documented limitation and ask how the team should handle it.
A simulation may not exercise every part of a live marketplace connection. If the remaining uncertainty matters, arrange a controlled live-service pilot with the marketplace and integration providers. Set the time, participants, monitoring method and stop conditions in advance. Discuss any real payment, customer communication or dispatch implications separately; none should be triggered by the practice scenario.
Make the decision and assign exceptions
Use three outcomes for each channel and destination. Pass means the agreed check showed the intended result, including the correct location and order details. Fail means an observed result conflicts with an acceptance criterion, such as an order appearing at the wrong restaurant or arriving with the wrong modifier. Unknown means the team could not observe or establish the result. An unsupported exception can be an accepted limitation, but it should not be marked as a passed check.
For each fail or unknown, name an owner, a due date and a next action. The marketplace contact might confirm the listing identifier; the integration provider might inspect the mapping; the restaurant manager might confirm the receiving device. Record who approves any temporary workaround and who has authority to postpone the rename. A workaround could mean staff monitoring the marketplace’s own order view while the provider resolves a mapping issue, if that workflow is available and the team can operate it reliably.
Set a retest date or event, such as completion of a remap, a channel reconnection or a listing replacement. Keep the old and new labels, identifiers, authorization status, observed order result and decision together where the operations team can find them. If the channel is not authorized, do not infer that orders will flow just because the names and identifiers look right.
Before purchase, compare written quotes for the exact locations, channels, devices, setup and support involved. Ask what changes when a listing is replaced and whether remapping or assistance has an additional charge. Fleksa’s plans page provides its published pricing, checked November 2026; confirm the current quote and scope for your setup. For a broader choice between direct POS connections and middleware, use the related buying guide.
Bring your before-and-after map to a Fleksa demo. Ask the team to demonstrate the proposed order path for your marketplace and POS, identify what can be safely simulated, and explain the next step for any unknown result.
Frequently asked questions
Does changing a marketplace store name change its location identifier?
Not necessarily. Ask the marketplace which identifier the integration uses and whether the planned change preserves it. Creating a replacement listing may require a new mapping.
Is an order at the right POS enough to pass?
Check the kitchen destination and order details too, including modifiers and total. Also verify that the order did not reach a neighboring location, using an agreed safe method.
What if a provider cannot simulate the rename?
Record the result as unknown, ask what evidence or supported check is available, and decide whether a controlled live-service pilot is needed before approval.
