Before buying a delivery integration, ask the vendor to show exactly where staff change preparation time and which channels receive that change. A button in one system does not necessarily update every delivery app, every location, or an order already in progress.
Make the decision by mapping each customer-facing estimate back to its source, then checking the control at the level your team needs: channel, location, or individual order. Separate a confirmed update from a manual step. A setup that requires two tablets may still work for a small operation, but staff need to know that before a rush starts.
Map the estimates customers actually see
Start with one location and list every way it receives delivery orders. Include direct online ordering, each marketplace app, and any orders staff enter manually. Repeat the exercise for other locations rather than assuming their settings match.
For each channel, identify the normal preparation time and where staff can see or edit it. Then ask what the customer sees: a preparation estimate, a pickup time, a delivery window, or some combination. A kitchen prep time and a delivery estimate are different things. A delivery window may also depend on travel or courier availability, so changing the kitchen value does not necessarily produce an equal change in the customer-facing window.
Draw a simple path for each channel: customer order, channel or integration, POS, and kitchen screen or ticket. Your restaurant POS system may receive an order without being the place that controls the estimate. Likewise, a value visible on a kitchen display is not automatically the value shown in the ordering app.
For every path, record the answer to these questions:
- What is the usual prep-time setting, and who set it?
- Which screen is the source of the value, and which screens only display it?
- Does the channel add other time when showing an estimate to a guest?
- Can staff see when a value was last changed and whether it reached the intended channel?
Mark unknowns as questions for the demonstration. If the vendor cannot show the guest-facing result, ask what staff can check instead and whether a separate channel login is needed. Do not treat a displayed setting as proof that the guest saw the corresponding estimate.
Match the control to your service needs
A useful prep-time control has the right scope. Ask the vendor to demonstrate each action with your actual location, channel, and POS combination. Review the available restaurant integrations first: a listed connection and an on-request connection are not the same purchasing commitment. Confirm availability and setup for your restaurant before building a process around either one.
Channel and location changes
Suppose a delivery app is busy but direct orders are moving normally. Can staff extend preparation time for that app alone? If they change a central setting, does it affect all connected channels or only selected ones? Ask whether a channel can override the central setting, and which value wins when the two differ.
Next, ask whether the control applies to one restaurant location or several. A group with a busy downtown kitchen and a quiet suburban kitchen needs to avoid changing both by mistake. Request a demonstration of the location selector and the confirmation staff see before saving.
Individual orders and timing
Ask whether staff can change the estimate for a single order, and whether that action affects only the kitchen workflow or also reaches the customer or marketplace. Find out whether the change applies to orders already accepted, only new orders, or both. If an order cannot be updated through the integration, document the separate action staff must take in the channel.
Also ask how quickly an update is expected to appear and what happens if it fails. A loading indicator, an error, and a confirmed update call for different responses. The wider choice between a direct connection and middleware can affect who owns troubleshooting; the related buying guide covers that architecture decision.
Keep a short list of required actions and acceptable manual work. For example, a manager might accept changing one marketplace tablet during a rush but not three. If a needed action is unsupported, treat it as a decision point: change the operating procedure, choose another setup, or decide the limitation is acceptable.
Simulate a rush without sending a real order
Use a simulation or a vendor-provided test environment that cannot charge a card, message a guest, or dispatch a courier. Do not assume a test label makes a live order safe. If the vendor cannot prevent those actions, use a walkthrough with hypothetical results instead of placing an order.
Hypothetical example: A restaurant has one location, direct ordering, and two marketplace channels. Its normal kitchen prep setting is 20 minutes. During a rush, the shift lead wants new orders from Marketplace A to use 35 minutes, while direct ordering and Marketplace B stay at 20 minutes. These are sample values, not a claim about any product.
Before changing anything, write down the expected result: Marketplace A should receive the new value for new orders; the other two channels should remain unchanged. The lead also needs to know whether existing orders keep their earlier estimate. Ask the vendor to show where the change is made, how the location and channel are selected, and what confirmation appears.
In a safe simulation, compare the result at each available point: the control screen, the channel view, the POS or kitchen view, and the guest-facing estimate if a safe preview exists. Record the time of each check and the exact value displayed. If the guest view shows a delivery window rather than prep minutes, record the window as a separate observation; do not label it a 35-minute prep time.
Use a unique test identifier if a simulated order is part of the walkthrough. Match the source order to its POS and kitchen result, including modifiers and totals. Ask the vendor to show how supported exceptions appear, such as a rejected update or an order that cannot be changed. An intentionally unsupported action is a documented limit, not a failed requirement unless your restaurant needs it.
The table below shows how the hypothetical team could record its expectations and next checks. The results are illustrative; they are not results from a product test.
| Control or check | Expected result | Illustrative observation | Owner and next decision |
|---|---|---|---|
| Marketplace A, new orders | Prep setting changes from 20 to 35 minutes | Control shows 35; channel and guest view not yet checked | Shift lead asks vendor how to verify both views |
| Direct ordering and Marketplace B | Each stays at 20 minutes | No change shown on the control screen | Manager checks each channel separately before approving the workflow |
| Marketplace A, existing order | Team needs to know whether its earlier estimate changes | Behavior remains unknown | Vendor demonstrates or documents the supported action |
| Rush ends | Marketplace A returns to 20 minutes | Reset has not been simulated | Closing lead practices reset and records the verification step |
Notice the difference between an expected result and an observation. Seeing 35 on the control screen alone does not establish that Marketplace A or its guests received it. If the vendor cannot demonstrate a step safely, leave it open and decide who will obtain an answer before purchase.
Assign the reset and handle stale values
A busy-period increase needs an end point. Choose who can make the change, who can reverse it, and what triggers the reset. The trigger might be the end of a rush, a manager handoff, or a kitchen-capacity check. Avoid relying on the person who made the change to remember it after leaving.
Put the normal value and reset steps in the shift handoff. The closing lead should check the affected channels, not just the central control. If the system offers an automatic reset, ask when it runs, which channels it covers, and how staff can tell it succeeded. If it does not, assign the manual reset explicitly.
Define a stale-value response as well. If the channel still shows the old value after the expected update period, staff should know which screen to check, whether to change the channel directly, and whom to contact. Write down the fallback for each channel rather than assuming one fix applies everywhere.
After a safe simulation, a live service pilot is a separate decision. Agree on staff coverage, monitoring, and a rollback procedure with the vendor before using the workflow during service. Real customer orders can involve real payments, messages, and courier activity, so they should not be used as practice scenarios.
Bring your channel list, location details, POS information, and these test cases to a Fleksa demo. Ask the team to show the relevant Uber Eats integration where applicable, and confirm availability and prep-time behavior for your restaurant's setup.
Frequently asked questions
Does changing prep time in the POS update every delivery app?
Not necessarily. Ask the vendor to demonstrate which channels receive the change for your specific POS and location, and how staff can verify the result.
Is prep time the same as the customer's delivery estimate?
No. Prep time describes the kitchen portion. A customer-facing delivery window may also reflect other factors, so compare the two as separate values.
What should staff do if a channel keeps the old estimate?
Follow the documented fallback for that channel, which may include checking the channel directly and contacting support. Assign someone to verify the correction and record the issue for follow-up.
