A future delivery order should be visible to someone responsible for it soon enough to catch problems, but it should not enter the kitchen’s active work queue so early that staff mistake it for an order to make now. The right timing depends on the promised delivery window, preparation time, courier handoff, and each system’s controls.
Before buying a restaurant delivery integration for scheduled orders, ask two separate questions: When can staff see the order? and when can they act on it? A provider may show an order on a tablet before it appears in the POS, or send it to the kitchen only at a later release time. Make the vendor demonstrate the path for your actual channel, POS, and location.
Build the timeline backward from delivery
Start with each location’s delivery channels and opening hours. Then identify the time the guest placed the order, the promised delivery time or window, the expected courier handoff, and the latest practical preparation start. Ask who sets each time and whether staff can change it.
Delivery time is not the same as kitchen start time. Travel and handoff take time, and food may need a buffer for packing. A large catering order may need a different lead time from one sandwich. If the system uses one release rule for every order, ask how staff handle exceptions.
The following is a hypothetical planning example for one location. It assumes a 6:30 p.m. promised delivery, a 15-minute delivery allowance, five minutes for packing, and 20 minutes for preparation. These are operating assumptions, not a vendor’s timing rules. No costs are included; the example compares timing only.
| Milestone | Example time | Staff decision |
|---|---|---|
| Guest places order | 10:00 a.m. | Confirm who can see it and check for problems. |
| Preparation starts | 5:50 p.m. | Kitchen begins the order. |
| Packing starts | 6:10 p.m. | Check items and modifiers. |
| Courier handoff target | 6:15 p.m. | Have the order ready for pickup. |
| Promised delivery | 6:30 p.m. | Guest expects delivery. |
Read the table backward: 15 minutes for delivery puts handoff at 6:15; packing begins five minutes earlier, and preparation starts another 20 minutes before that. If the courier timing or kitchen workload changes, the preparation target changes too. The restaurant needs to know whether the channel, aggregator, or POS controls that target—and what happens if none of them can adjust it.
Visibility at 10:00 a.m. would help a manager spot an unavailable item. A kitchen release at 5:50 p.m. could help avoid cooking too early. Those are useful targets for this example, not requirements every provider will meet. Decide which staff member owns the gap between early visibility and kitchen action.
Ask what appears, where, and what staff can do
Make a separate row in your evaluation for every important channel, POS, and location combination. A connection listed in a directory is a starting point, not an answer to the timing question. Fleksa’s restaurant integrations directory distinguishes live connections from those available on request. Availability and setup can vary.
For each combination, ask the vendor to show a scheduled order from placement through kitchen handoff. The demonstration should identify the time in the channel, aggregator, POS, and kitchen display or printer, if used. Ask whether the promised time shown at each step is a delivery time, pickup time, or kitchen release time.
Use questions like these to separate an actual control from a manual workaround:
- Can a manager see the order as soon as it is accepted, even when the kitchen cannot yet act on it?
- Does the order enter the POS immediately or only at a release time? Can staff search for it before release?
- Can staff accept, reject, edit, cancel, or change timing from each screen? Which actions must happen in the original channel?
- What sends the ticket to the kitchen or printer, and can staff release it earlier or hold it back?
- How are modifiers, special instructions, totals, and later changes shown?
- What alert appears if the order cannot reach the POS or kitchen? Who must check it?
Ask for a demonstration using your planned setup, rather than assuming that an example from another channel will behave the same way. For example, if you use Uber Eats, discuss the specific setup described on Fleksa’s Uber Eats integration page and ask how a future order moves through your POS. If you are considering a different restaurant POS system, ask the same questions for that combination.
Otter’s Order Manager page describes consolidating online and manual orders on a tablet, automatic acceptance and printing, and POS connections. Ask how scheduled-order visibility, release, and changes work with your exact channel and POS before treating those general functions as a fit.
Record the answer as an action, not simply “supported.” For example: “Manager can view on the aggregator; cancellation must be done in the channel.” If an action is unavailable, decide whether the manual step is acceptable and who will perform it. An unsupported action is a limitation to plan around, not automatically a failed purchase.
Run a safe handoff test across closing and reopening
A daytime demonstration may miss the moment when responsibility changes between shifts. Create a simulated order placed before closing for delivery after the next reopening. Use a vendor-provided test mode or another safe simulation that cannot charge a card, message a guest, or dispatch a courier. If the systems cannot support a safe end-to-end simulation, review the steps with the vendor using a hypothetical order instead.
Give the test order a unique identifier that contains no private customer information. Include an item, a modifier, an instruction, and a total so staff can match the source order to the POS and kitchen result. Use an agreed test location and label the scenario clearly so nobody prepares it as real food.
Before starting, write down the expected result at each point. The closing manager should be able to identify where the future order is recorded and leave a handoff for the opening manager. After reopening, the opening manager should know where to check it, when it is due for release, and what to do if it is missing. At the planned preparation time, the kitchen should receive—or be told to retrieve—the order through the agreed process.
During a simulation, record what actually appears and when. Match the identifier across the source, aggregator, POS, and kitchen destination. Check the modifier, instruction, promised time, and total at each available step. Note any manual action separately from an automatic handoff. Do not mark an order as passed merely because a notification appeared on one screen.
Then simulate the exceptions the setup is meant to handle: a changed promised time, an unavailable item, a cancellation, and a failed POS or kitchen handoff. Ask the vendor how to simulate each safely. If a case is intentionally unsupported, record the limitation and the staff workaround instead of treating it as an automatic failure.
A simulation checks the configured path; it does not prove how a busy service will unfold. If you later conduct a live service pilot, use genuine orders under normal operating procedures, with staff assigned to monitor them. Do not create real payments, guest messages, or courier dispatches merely to practice. Agree in advance on how staff will respond to a missed or changed order during service.
Give every exception an owner and a next decision
The software can surface an order, but someone still needs to notice and act. Put scheduled orders on the closing and opening checklists. The closing manager can review future orders and flag items that need attention. The opening manager can confirm the list against the relevant channel or aggregator and resolve issues before preparation begins. Assign a backup for each role.
For each unresolved question, write down the owner, deadline, and decision. For example, if a cancellation is visible only in the channel, the owner might be the shift manager; the decision is whether that manager can reliably check the channel before kitchen release. If not, ask the vendor for another workflow or consider a different setup.
Also agree on the response when an order is missing, duplicated, changed, or due while the kitchen is closed. Identify which screen is the reference for the next action, how staff reach the channel or provider for help, and who tells the kitchen to stop or start work. Do not assume a change made in one system reaches every other system until you have seen the behavior for that combination.
Compare the operational quote for each option alongside this workflow. Ask what setup, recurring software, support, and any channel-related charges apply, and which exception-handling tasks remain with staff. A lower quote may not suit the restaurant if it leaves a critical handoff dependent on an unchecked tablet. Get contract or tax advice from a qualified adviser where needed.
For a broader comparison of connection models, see the guide to direct POS integration and middleware. Then bring your channel list, location details, and scheduled-order test cases to a Fleksa demo, and confirm availability for your location.
Frequently asked questions
Should a scheduled order appear immediately in the kitchen?
Not necessarily. Early manager visibility can help catch problems, while a later kitchen release can reduce the chance of cooking too soon. Confirm how both timings work in your setup.
What if a scheduled order changes after it is placed?
Ask where the change appears, whether staff must act in the original channel, and how the kitchen learns about it. Assign a person to check unresolved changes before preparation.
Can one test cover every delivery channel?
No. Test or review each important channel, POS, and location combination. Timing and available actions may differ, so record the result and workaround for each one.
